I have subclasses of OrderedCollection in my domain model. These subclasses have instance variables.
In OmniBase, OrderedCollection has a custom serialization-deserialization strategy and has its own class identifier byte.
This strategy ignores the instance variables of my OrderedCollection subclasses. Should I add a class identifier for my subclasses and create my own serialization strategy for them? If so, can I pick any arbitrary class identifier byte that's not taken by another class (I actually get errors when I try to do that...).
Am I violating smalltalk style by giving my collections instance variables?
Thank you in advance.
Derek Brans Nerd on a Wire Web design that's anything but square http://www.nerdonawire.com phone: 604.874.6463 mailto: brans@nerdonawire.com
Am I violating smalltalk style by giving my collections instance
variables?
Yes. It's much more common to think about (domain object A) *having* a collection of (domain object B), rather than *being* a collection.
The collection subclass isn't a domain object so much as it describes a relationship between domain objects.
This collection notifies a listener when its contents have been changed.
What is a more ideal implementation this type of object?
Thank you.
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, ...
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@nerdonawire.com phone: 604.874.6463 toll-free: 1-877-NERD-ON-A-WIRE ----- Original Message ----- From: "Cees de Groot" cg@cdegroot.com To: "The general-purpose Squeak developers list" squeak-dev@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, ...
On Tue, 2003-06-10 at 04:56, Derek Brans wrote:
Why does OrderedCollection need a unique class-identifier byte? Is it because it uses custom marshalling?
Probably more as a bootstrap for marshalling - if you do custom marshalling for a class, you don't need to manually assign class identifiers (also see some remarks on my (erroneous) explanation of OmniBase serialization on the OmniBase Swiki by David).
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?
No, I don't think it will. But then, I have always resisted the temptation to subclass inside the Collection hierarchy ;-). Try it, I'd say...
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?
Of course. Just remove the exception-generating code in BlockContext ("you cannot marshall me") with something that serializes the BlockContext. I've tried it once, but got bitten by the problem of where to stop tracing the transitive closure from a given instance - my database started to fill with most of my image ;-). This was in VW, where Namespaces got serialized by value instead of by name (like classes etcetera should be serialized). But if you can cook up a satisfactory external representation of a BlockContext, nothing stops you from dumping it in an OmniBase db....
(also see some remarks on my (erroneous) explanation of OmniBase serialization on the OmniBase Swiki by David).
link?
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?
No, I don't think it will. But then, I have always resisted the temptation to subclass inside the Collection hierarchy ;-). Try it, I'd say...
Yes, any subclass is serialized and returned as an OrderedCollection. I am trying to create an OrderedSet based on OrderedCollection. I'll rethink that and maybe use Set instead.
Thanks for your response.
Derek
squeak-dev@lists.squeakfoundation.org