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

> 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?

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

Marcel