> ** Original Sender: Marcel Weiher <marcel at system.de>
> > From: Alan Lovejoy <sourcery at 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