Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:11 am
by JADE News Administrator >> Wed, 28 Oct 1998 23:24:13 GMT
I didn't make myself very clear. In discussing user defined primitives, I was talking about two concepts: (i) the ability to subclass existing primitives (which I took for granted), and (ii) the ability to define embedded types (user primitives, composites, records, or embedded objects - as Carl referred to them - which is a good term). Subclassing existing primitives suffices for simple types such as an AccountNumber, where all you probably want to do is constrain the existing String type (eg: define the length, perhaps specify its range, etc) and add some methods. But for more complex types (eg: an Address), this won't do. What's required is the ability to embed instances of Address in their parent, which is what Jade does for primitives so this concept could be extended. Alternatively, we could extend the concept of exclusivity (currently only applicable for collection properties where it's used to define either an exclusive or shared collection) so that when applied to a non-collection reference, the object becomes embedded. Whatever approach is taken, what we've had in mind is the provision of both (i) and (ii).
The decision to distinguish between classes and primitives, and not to treat everything as an object was a deliberate one; trading off OO purism for performance and practicality. Creating primitives as objects to which their parents hold references (eg: a Customer would have *references* to its name, address, phone number, etc) has significant performance implications. Retrieving a Customer instance would effectively return only a set of references; accessing "name" would dereference it which would require another fetch from the database, likewise for "address", "phone number" and so on. This is inefficient. It increases the number of requests to the database, and for every piece of primitive data there is the space overhead of a reference and object header as well. This impacts space (both disk, and memory which in turn impacts cache utilization) and increases network traffic. Optimizations such as automatically fetching referenced objects, and storing primitives by value but with a type indicator can reduce the database requests but still impact space. In the majority of cases, you want properties like "name" and "phone number" to be embedded and behave as primitives with no overhead. In cases where you want the property to behave like an object (eg: for polymorphism), you can implement this yourself by encapsulating the property in a class and referencing an instance of the class. In distinguishing between classes and primitives we made a conscious decision not to penalize the majority of cases.
Dean.