Object Data Instance Notation - ODIN library

Indeed, it is interesting and sparks a thought in me from what has been shared so far: Some form of these notations could be applied to code as some sort of a "complex constant" -- that is -- when accessed by a Client, the Eiffel code would construct the complex object from the static definition. Because it is a mixture of manifests and statically defined reference types, the compiler would still be able to apply static type checking as long as the complex constant was typed to an existing class in the project universe. Eric, your example, I would re-write as:

ledger: LEDGER = [ name: STRING = "cbot" tag: STRING = "market" tracing: STRING = "off" template: STRING = "market" business_id: RECORD = [ market: STRING = "cbot" contract_spec: STRING = "" contract: STRING = "" category: STRING = "market" my_counterpart: RECORD = Current.parent.all_cspecs_id ] all_cspecs_id: RECORD = [ market: STRING = "cbot" contract_spec: STRING = "*" contract: STRING = "" category: STRING = "contract_spec" my_counterpart: RECORD = Current.parent.business_id ] reference_to_self: {like Current} = Current internal_array: {like Current.parent.parent.another_feature} = Current.parent.parent.another_feature another_feature: ARRAYED_LIST [INTEGER] -- Some other feature to reference from within `ledger'. attribute create Result.make (0) end

Above, the structure is similar to writing an Eiffel constant, except the object is allowed to be more complex. In this case, a reference type like LEDGER is allowed to be represented as a new form of named TUPLE, where the named elements are themselves allowed to be constants and complex constants. Thus, the elements: name, tag, tracing, and template are all STRING constants, whereas the reference types business_id' and all_cspecs_id' are references to RECORD. Each instance of RECORD is allowed to be another new manifest TUPLE form, with its own set of constant elements.

In this way, the `ledger' feature in our class will be a Once that returns a single object and reference, unless (of course) it is twinned (i.e. my_ledger := ledger.twin).

Moreover, this same structure can be stored in a file, is quite human readable, and is easily a specification for both serialization and deserialization.

Also, reference class references within the complex constants would have to exist somewhere in the class universe so the compiler would have oversight of them. In this case, the class RECORD would need to already exist. Additionally, RECORD would need to satisfy Void-safety for all of its attributes. Attached attributes would need to be provably attached when each instance of RECORD is built. Invariant contracts would apply at the end of the creation cycle for the reference class. Perhaps a flaw in the thinking is that (e.g. blah: STRING = "another_blah") the value of the attribute would be valid. One would be limited to trusting programmer discipline to get the values of manifests like STRINGs correct (e.g. "another_blah" might not be a legal value and a validator might not be achievable, if the STRING is complex enough. Perhaps one could open the door to the constant being set by some call on the RECORD class at creation time (e.g. blah: STRING = Current.calculate_my_blah)? Yet, for a specification that is strictly applied to serialization and deserialization of objects to and from text, such things are not needed as the values are known from the objects being serialized to text.

I have added one more feature to your example to see how Current would apply. In this case, the feature is reference_to_self'. A more interesting problem would be to provide a reference between business_id' and all_cspecs_id'. In the code above, the example is that one can simply use Current.parent' to drill up and then back down. In this manner, one could make complex references between the objects in the complex constant.

It is further conceivable that one could make references outside of the complex constant. In the code example above, the internal_array' reaches above ledger' and then back down to `another_feature' in the same enclosing class. However, such a thing would not look this way when serialized to text for storage in some data repository.

For me, the dual applicability of the notation to both the creation and use of complex constants and to the serialization and deserialization of objects to and from text is highly intriguing. The code is so much like what Eiffel is already, simple, elegant, and flexible in its capacity to model complex objects as constants. I am liking it the more I look at it.

More food for thought! :-)