On Sun, Aug 31, 2003 at 02:59:47AM +0900, Charles Hixson wrote:
> >The marshalled form of an object contains only the class name and the
> >instance variables; it does not include the methods of the class. You can
> >see this if you use 'inspect' on the output of Marshal.
> >
> >So if you redefine class Foo, when you load in an old object it will be of
> >the new Foo class. In any case the object does not contain the methods of
> >Foo, it contains only a pointer to the class Foo.
> >
> >This is why you can't marshal an object with singleton methods.
> >
> Hmm.  I can certainly see how that would simplify things.  But it 
> definitely implies that marshalled output can't be transferred between 
> computers.  And probably not even between processors on the same 
> computer (what with on-the-fly class construction and modification).  
> What would one use for that?  You certainly don't want a copy of the 
> code for every instance, but I don't see the do-able inbetween position.

No, it doesn't imply that marshalled output can't be transferred between
computers - that's exactly what DRb does.

Both ends have to have the same class definition, so you just do
    require 'foo.rb'
at both sides to get the definition of class Foo. An instance of Foo can
then be marshaled at A and unmarshaled at B.

If you modify class Foo, say by adding a new method, then clearly the new
method will not appear on the other machine unless you make the same change
there.

But that's how it has to be, unless marshaling an *instance* of Foo would
also marshal the *class* Foo, and all its superclasses and mixins for that
matter (including Object). If Ruby supported that, then a single instance
object would be huge. It would also be a huge security risk, as you'd be
passing across code or AST from one machine to another. Plus there are loads
of inconsistent situations I can imagine [*]

But in all practical applications I've used, it doesn't matter: marshaling
an object of class Foo with instance variables @x,@y,@z then unmarshaling it
simply creates a new instance of Foo (whatever Foo is today) with those
instance variables, and that's exactly what is needed.

Regards,

Brian.

[*] Imagine that 'a' is of class Foo, then I marshal it to disk. Then I
modify class Foo, and create another instance of Foo ('b'). Then I reload
'a' from disk. Should class Foo be reset to its original definition? Either
way, either 'a' or 'b' will not be the same as when it was originally
created, because both 'a' and 'b' are of class Foo and therefore have
identical sets of instance methods at any moment in time.

In a dynamic situation where Foo is being changed over time, you have to
accept that object 'a' which was created as an 'old Foo' will by necessity
become a 'new Foo' as Foo is changed.