Hi Cees,

Why does OrderedCollection need a unique class-identifier byte?  Is it
because it uses custom marshalling?

If so, then when you replied:
> I think you can get away with just re-implementing the serialization and
> deserialization code, OmniBase will take care of assigning identifiers.

you would be incorrect because you needed to create a magical byte for
OrderedCollection.

As an aside, wouldn't any subclass of OrderedCollection get marshalled and
unmarshalled as an OrderedCollection, instead of the subclass?  If so, isn't
that bad?

Also, suppose I want to implement BlockContext serialization (ie I don't
need my database to be dialect neutral).  Can't I have that option?

Thank you thank you.

Derek Brans
Nerd on a Wire
Web design that's anything but square
http://www.nerdonawire.com
mailto: brans at nerdonawire.com
phone: 604.874.6463
toll-free: 1-877-NERD-ON-A-WIRE
----- Original Message -----
From: "Cees de Groot" <cg at cdegroot.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, May 18, 2003 11:57 PM
Subject: Re: Omnibase and subclasses of OrderedCollection


> 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, ...
>
>
>
>
>
>