* Øystein Grøvlen <Oystein.Grovlen@stripped> [09/05/25 00:33]:
> >> The way I have understood it from discussions in the re-engineering
> >> team, I am not going to transfer ownership of data from Item to Value.
> >> So far, Value objects are just used for return values that can easily
> >> converted to other types.
> > Could you please explain with an example how it is going to be
> > easier with your patch?
> What will become easier is to add new basic types to the item type
> system. E.g., to introduce timestamp as a separate type. With the
> current design that would mean adding val_timestamp methods to hundreds
> of classes. With the Value methods, a new Value::to_timestamp() method
> is all that is needed.
I asked for an example, I would really appreciate something more
From your explanation it's not clear how the current patch
is better than just having:
Is it because the above always leads to a conversion?
But how would Value avoid this conversion? How would
it get timestamp value assigned to it to start with?
Suppose we overcome this problem, how is it better than having:
In other words, what exactly do you attain by having 7k lines of
changes that change item->val_int() to item->value()->to_int()?
You can have a default implementation of val_ methods in the base
To the second point. Just adding Value::to_timestamp() will not
add a timestamp support to the item hierarchy.
Consider BETWEEN function.
a BETWEEN <item1> and <item2>
if (a > item1->val_int() && a < item2->val_int())
But integer comparison and date comparison rules are different.
So BETWEEN function will not auto-magically start returning
a correct value just because you added value->to_timestamp().
A data type is a set of values plus a set of operations.
Without codifying and implementing operations on Value one
will not have a single place for adding a new data type.