You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When model options declare a type which $extends another type, it is possible to specify options for a property which already exists on the base type. A good use case for this is to define a property on a base type, then configure it to be calculated for a sub type:
However, in this example, the configuration of the sub types' HasPower property to be calculated inadvertently configures the base type's property to be considered calculated. This pollution of the property, which is shared for all three types in the above scenario, can lead to unexpected behavior. In this example, the property won't be properly initialized for an instance of Device since the framework thinks it is calculated, and should not be initialized to the default value for Boolean properties (false).
The root of this problem is the storage of certain, type-specific, metadata on the Property instance itself, such as whether or not the property isCalculated. Ideally, a property can be configured such that it has variable behavior for sub types, even though the property is declared on the base type. Behavior would include (but not limited to) things like if/how the property is calculated, whether or not it has special initialization logic, or whether or not that property is required to be filled out for the sub type.
Ideally, this problem would be solved by storing this metadata on a secondary object that is tied to the type for which the metadata was declared, instead of on the property itself.
The text was updated successfully, but these errors were encountered:
When model options declare a type which
$extends
another type, it is possible to specify options for a property which already exists on the base type. A good use case for this is to define a property on a base type, then configure it to be calculated for a sub type:However, in this example, the configuration of the sub types'
HasPower
property to be calculated inadvertently configures the base type's property to be considered calculated. This pollution of the property, which is shared for all three types in the above scenario, can lead to unexpected behavior. In this example, the property won't be properly initialized for an instance ofDevice
since the framework thinks it is calculated, and should not be initialized to the default value forBoolean
properties (false
).The root of this problem is the storage of certain, type-specific, metadata on the
Property
instance itself, such as whether or not the propertyisCalculated
. Ideally, a property can be configured such that it has variable behavior for sub types, even though the property is declared on the base type. Behavior would include (but not limited to) things like if/how the property is calculated, whether or not it has special initialization logic, or whether or not that property is required to be filled out for the sub type.Ideally, this problem would be solved by storing this metadata on a secondary object that is tied to the type for which the metadata was declared, instead of on the property itself.
The text was updated successfully, but these errors were encountered: