Am 15.06.2013 01:17, schrieb Daniel Werner:
How would you use that additional type information?
For rendering the value, mainly. It seems awkward that I would have to look up
the property's data type in order to render a value associated with that
property. Who sais that values can not exist without being associated with a
property?
To me it seems natural that the data structure representing the value should be
self-contained - that includes that it knows it's type. That way, the data
structure contains all information necessary for interpreting it.
A PropertyValueSnaks (PVS) referencing a certain
property can still have ANY
value of ANY value types, e.g. a value not necessarily matching the property's
data type's data value type. This is something all code should consider and
handle well.
Code that assigns a new value to a given property, that is, code that creates or
updates a snak value, needs to make sure that the value has the correct type for
the given property. We currently already do this for the DataValue-type.
All other code handling the value would just look at the value's data type, and
not care about the property or it's type.
If you want to put the PVS's property's data
type ID into the PVS instance, then
what would that data type ID be? What would be the precise definition of that
additional field?
It would be a data type identifier given as a string in the PVS's data structure.
* Would you take the ID of the PVS's
property's current data type?
--> you still had to load the properties then when building the Snaks. Just
moving that inconvenience somewhere else.
Yes, that wouldn't give us much, except for cleaner code for handling snak values.
* Or would you save that ID as part of the data model
within the Snak already?
In that case the ID would refer to the PVS's property's data type at the time of
the Snak's construction.
Indeed. It would refer to the values *actual* data type, allowing us to
interpret it correctly (especially for output, in the UI, in dumps, etc) even if
the property's type changes.
Currently, a property's type can never change - if it changed, we would lose the
ability to interpret values that are already in the database.
- The data type of the property could have changed (we
don't support changing
that as far as I know but I'd always consider it). So you still had to fetch the
property to compare its current data type with the one of the snak.
Why would I have to check that? I'm trying to interpret a value for output or
such, why should I (need to) care about the property's type?
Only when *setting* a value we need to do this check, and we already need to
check the datavalue's type in that case anyway.
- The data type's structure could have changed
(e.g. using a different data
value type). So even though your PVS is still referring to the same data type as
the PVS's property, the PVS's value might not be valid against that data type
anymore. Something you still had to consider and check for.
That is no different from the current situation. The code for creating value
objcts (Snaks, DataValues) from array structures must be backwards compatible in
any case, otherwise we lose access to existing values in the database.
--> all your type ID field would really stand for,
would be "The data type the
PVS's value has been valid against at the time of its construction". At what
point is this information really useful? In how many cases can this really spare
you loading the PVS's property to look up the actual data type?
In all cases except when setting the value.
Also, we might add other attributes than
"datatype" to properties at some point,
some might influence validation (e.g. the unit of a number). Would you then go
ahead and add these information also to the PVS's constructor?
No, because it is only relevant for validation, that is, when the value *changes*.
The point of having the value be self-contained and know it's type is to be able
to *interpret* it safely without contextual knowledge. That would be far more
robust than the current situation.
-- daniel