** Original Sender: Marcel Weiher marcel@system.de

...

From: Alan Lovejoy sourcery@pacbell.net

To say nothing of selector names. What's the Java/C++ translation of a Smalltalk message selector such as #displayOn:at:clippingBox:colorPalette:? And the inverse problem would also have to dealt with: Smalltalk

wants a

...

colon-terminated keyword for each argument.

Well, since this is about moving *objects* not *code*, there is actually no problem.

But in Smalltalk, code can be objects. Classes and methods are objects. Objects can hold classes and methods in their instance variables--and often do!

...

And then there's the universal problem of different class

libraries, with

...

each language's (or implementation's, or environment's) idiosyncratic set of names, capabilities and semantics of entities and operations.

Although all of this is beyond the scope of what I was talking about, having a self-describing format helps, because tools such as XSL could be used to transform between the serialization formats of superficially incompatible systems. Deeply incompatible systems will have to be modified to talk to each other, what did you expect?

I expected nothing, of course. I was not the one hoping to develop or use a universal object serialization format, remember?

...

How would Java/C++ deal with #doesNotUnderstand:? Or with

"thisContext"?

...

Or with a metaclass (which would also have to be dealt with, in

addition to

...

classes as objects)? What about #become: and

#changeClassToThatOf: (VW)?

...

What about adding/removing/redefining classes and/or methods as the program runs?

All of these are runtime issues that have little or nothing to do with serialization of objects. Geez, who was talking about magically turning C++ into a dynamic language via a common serialization format? Get a grip.

These things have everything to do with serialization of objects, if the objects in question are Smalltalk objects (see above). It was not clear from the prior discussion that you wanted to exclude classes and methods from consideration, and simply assume that the receiving system already had all the required classes/methods.

I agree that it would be both possible and useful to design a class library that would allow exchange of serialized objects between Smalltalk and Java (or perhaps even C++), provided certain constraints were respected (the Smalltalk objects to be serialized and exchanged with the Java/C++ world must not have instances of certain problematical classes anywhere in their object reference graph).

--Alan