You are here: Home V2 Software Software More ... Developer Notes Memops Code Generation DataObjTypes, mutable and not

DataObjTypes, mutable and not

The current status of DataObjTypes, and propoerties of a possible mutable DataObjType. Implemented Rasmus Fogh 2008


DataObjTypes are objects without object identity - they compare by value. They may not participate in links to class objects. They can have attribute of either simple type (DataType) or complex type (DataObjType). Connections to attributes are one-way (containment)- you cannot get from a DataObjType instance to its 'owner'. A DataObjType can not contain instances of its own type either directly or indirectly - this makes recursive and cyclic structures illegal. Their internals are encapsulated. They may have the full range of constraints and restrictions, and may have functions like class objects.


Immutable types

The current implementation only allows immutable types. Their behaviour is similar to a primitive type like an integer or complex number. They are hashable, comparable and sortable. All their attributes must be frozen, and attributes of complex type must have an immutable type as well. Immutable types compare by value, and are hashable. Since the types are immutable you cannot modify a DataObjType object that is attached to another object. This is a requirement - if you allowed this you could no longer guarantee the internal data in your objects from casual modification.
Immutable DataObjTypes can be created in an override state by passing 'override=True' into the constructor. This suspends validity checking and allows you to add attributes to already created objects. For technical reasons objects have to be accepted as valid by validity checking code also if override=True. It is up to the programmer to reset override to False when he is finished making changes - though override status is not stored (to files at least). The endOverride function resets override to False. Override can not be set on an existing object, except by bypassing the API. Note that changing the internals of existing DataObjType objects can render invalid dictionaries etc. that use the for keys. Bypassing the API chould be done only with extreme caution.

Mutable types

Immutable DataObjTypes are a bit limited. Certainly most uses for matrices would require mutable objects. So, how could we allow mutable types without breaking data encapsulation?

First of all, mutable types would be an addition to the MetaModel. The existing immutable DataObjTypes (and their generation machinery) would remain unchanged. Also the mutable DataObjTypes would still obey the rules given in 'Definition' above. Their behaviour would be similar to that of a container object, like a Python list. They would not be hashable.

To preserve data encapsulation, all mutable DataObjTypes would be cloned when they were attached to an attribute, be it the attribute of a Class object or a DataObjType object. They would also be cloned when returned from a getter function. In this way there would never be any outside reference available to the DataObjType objects held internally in other objects, and you could never have the same DataObjType object appear inside more than one other object.

Mutable DataObjTypes could be created on their own, but they would not be persisted unless they were attached, directly or indrectly,  to a class object.

The main problem with the mutable DataObjType implementation would be the cloning. If you had large or deeply nested objects, all the copying would be fairly slow. The lack of facilities for recursive or cyclical data structures is another limitation. A better implementation that still preserved data encapsulation would be welcome, but someone else would have to think of one.