The is-a Property in Atomic Data is of the resourceArray URL. This means that any Resource can be an instance of mutiple Classes. However, at this moment, there is not a single Resource that does this.
The Property class in Atomic Data is perhaps the most important one of all. It's currently growing by adding properties like is-dynamic and is-locked. That's not necessarily bad, but there is a risk of having a bloated, confusing class. Also, some properties of Property are only relevant to specific datatypes. For example, setting a maxLength is only relevant on strings. Having a classType is only relevant for AtomicURL or ResourceArray types of properties. One solution of dealing with this, is to add new classes for specific datatypes, e.g. PropertyString or PropertyAtomicURL, which then have some properties of their own.
Questions
Since the type of additional Property can depend on the values of the instance, it might be possible to infer these (e.g. if we set Datatype in a Property to String, we might need to infer the PropertyString class). Maybe this should be the responsibility of the type system of Atomic? It's probably way too complicated, but it would help in rendering forms that depend on inputs.
The
is-aProperty in Atomic Data is of theresourceArrayURL. This means that any Resource can be an instance of mutipleClasses. However, at this moment, there is not a single Resource that does this.The reason I opted for mutli-class, is because of the advantages that Composition over Inheritance brings.
Usecases
Propertyclass in Atomic Data is perhaps the most important one of all. It's currently growing by adding properties likeis-dynamicandis-locked. That's not necessarily bad, but there is a risk of having a bloated, confusing class. Also, some properties of Property are only relevant to specific datatypes. For example, setting amaxLengthis only relevant on strings. Having aclassTypeis only relevant forAtomicURLorResourceArraytypes of properties. One solution of dealing with this, is to add new classes for specific datatypes, e.g.PropertyStringorPropertyAtomicURL, which then have some properties of their own.Questions
String, we might need to infer thePropertyStringclass). Maybe this should be the responsibility of the type system of Atomic? It's probably way too complicated, but it would help in rendering forms that depend on inputs.