[Q][magma] MaObjectSerializer documentation and usage

Chris Muller afunkyobject at yahoo.com
Tue Jun 10 20:42:51 UTC 2003


> Chris, it looks like it took at least several weeks for you to write 
> Magma.

Ha!  I only wish!  The initial concept for Magma actually started in February
2000.  I spent about ten hours a week since then to build and assemble the
independent frameworks that make it work the way it does today.  Thankfully,
the codebase ended up relatively small and dense, so I prefer to think of it as
a fine instrument than a giant bulldozer.  :-)

> When materializing a byteArray, I also need to substitute objects for 
> descriptors.

If your descriptor instances only purpose in life is to be friendly to
serialization/materialization, and not intended to be used by the external
program which works with the serialized/materialized objects, then I think
you'll be happier with not using substitutions at all.  That's because, under
that scenario, there is a cost incurred to materializing the descriptor and yet
is an object that nobody wants.  You only want it so that it can be converted
to the object it describes.

To illustrate, pretend the serializers traversalStrategy has a method called
"realObjectForSubstitute:" which takes the substitute and gives you back the
original (the opposite of what it already has, which is "substituteFor:").

If it had this method, you could then use the serializers existing method,
materializeGraph:do:, which lets you send a message to each object "a la
postMaterialize".  Unfortunately, you'd be forced to use a become: if you
wanted the object model to be materialized exactly as it was serialized:

	mySerializer
		materializeGraph: aByteArray
		do: [ : eachMaterializedObject | eachMaterializedObject isDescriptor ifTrue:
[ eachMaterializedObject become: (mySerializer traversalStrategy
realObjectForSubstitute: eachMaterializedObject) ] ]

Now, if my assumptions above are correct, that you only want descriptors for
serialization purposes, I found it to be better to just materialize the *real*
object straight from the buffer in the first place.  It was more efficient,
avoids the become:, and was less confusing for me.

> You seem to be 
> recommending that I use special ObjectBuffers that materialize to the 
> correct object.

Not trying to "recommend" anything without a full understanding of your
context, sorry.  It wouldn't be a special ObjectBuffer, it would be an existing
one, ByteObjectBuffer.

> The difficulty is that I need to register connection 
> oids for this ObjectBuffer.  I don't see where I could do that, since I 
> don't have a reference to the serializer in this method.

Not sure what you mean by "connection oids".  Keep in mind that all the oid
assignments will be made inside the serializer automatically when you
materialize, no need to worry about that yourself.

Perhaps you could give me some more concrete details, or perhaps a simple code
sample that demonstrates what you're wanting to do.

Regards,
  Chris

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



More information about the Squeak-dev mailing list