Omnibase and subclasses of OrderedCollection

Cees de Groot cg at cdegroot.com
Mon May 19 06:57:32 UTC 2003


On Mon, 2003-05-19 at 03:01, Derek Brans wrote:
> In OmniBase, OrderedCollection has a custom
> serialization-deserialization strategy and has its own class
> identifier byte.  
>
When you are threading the path of custom marshalling in OmniBase, it's
a warning sign. I'd follow the advice of Avy and make the collection an
instance var of a custom class. 

> Should I add a class identifier for my subclasses and create my own
> serialization strategy for them? 
>
I think you can get away with just re-implementing the serialization and
deserialization code, OmniBase will take care of assigning identifiers.
If you really want to subclass a collection class, your
serialization/deserialization methods should be a mix of the Collection
and Object methods. 

In a fairly complex project I currently only have 2 places where I use
custom marshalling in OmniBase: one has to do with a SortedCollection,
which is marshalled as an OrderedCollection and on demarshalling gets
its default sortBlock back(*), the other one is my DataValue/Attribute
stuff where on marshalling the reference to an Attribute is replaced by
a symbol and on demarshalling the symbol is looked up in the class-side
attribute dictionary and linked back to the object find there. As you
can see, both fairly simple cases of special treatment of a single
instance var, I haven't had to resort to a full override yet.

(*) before y'all scream ``why can't OmniBase store SortedCollections
directly'', the main reason is that OmniBase won't serialize blocks, and
that's more a design limitation than a technical limitation - by
refusing to serialize blocks, the OmniBase database format stays
dialect-neutral so you can hook up to the same database from Squeak,
VisualWorks, Dolphin, ...





More information about the Squeak-dev mailing list