When one marshals a constant and later unmarshals it, a brand new object
appears to be created during unmarshalling. This seems wasteful,
especially
in cases when constants are large (contain many attributes). Is it
possible
to customize marshal for a class (or for singleton objects of the class)
so
that unmarshalling a constant simply returns the already existing
constant
rather than creating a new one? I’ve noticed Fixnum’s exhibit this
behavior.
–Brian
class A;
A1 = A.new
end
before = A::A1
after = Marshal.load(Marshal.dump(before)) #marshal and back
puts before == after #darn – it is false
puts before.object_id == after.object_id #same here
it works for Fixnums
before = 123
after = Marshal.load(Marshal.dump(before))
puts before == after # true
puts before.object_id == after.object_id #also true
That’s because Fixnums are immediate values, and thus they compare by
value.
You can’t possibly have two distinct Fixnum objects representing for
example
123 short of doing some very sick core interpreter hacks.
The comparing of the objects fails, because by default, objects compare
by
reference unless overridden.
Also, Marshal also has completely no way of telling if the object is a
constant or not. For that matter, I don’t think there even is such a
thing as
a constant object in Ruby, you can only design objects as immutable, and
have
constant object references.
I also don’t think Marshal is even supposed at all to return completely
the
same object if possible on loading, it’s supposed to recreate an object
with
the same structure (optionally between two runs of an interpreter). If
anything, the change you propose might end up breaking code that could
use
Marshal for simple deep copying of Objects as is common in Java / .NET.
(I
don’t recall at the moment if there’s any Ruby-specific deep-copy
functionality)
David V.
DÅ?a Utorok 07 Február 2006 20:38 Brian B. napÃsal:
DÅ?a Utorok 07 Február 2006 21:39 Joel VanderWerf napÃsal:
self.class.name_for_constant(self)
puts before.object_id == after.object_id # ==> true
Ignore the nonsensical rant that follows after the explanation about the
Fixnums, I thought Brian wanted to change Marshal code for some reason.
before = A::A1
after = Marshal.load(Marshal.dump(before)) #marshal and back
puts before == after #darn – it is false
puts before.object_id == after.object_id #same here
def _dump(limit)
self.class.name_for_constant(self)
end
def self._load(str)
const_get str
end
end
Whoa. I see it works (for the A constants only as written, getting
TypeErrors on A non-constants). I don’t understand why it works just
yet.
Will examine further tonight.
that unmarshalling a constant simply returns the already existing
constant
rather than creating a new one? I’ve noticed Fixnum’s exhibit this
behavior.
How do you know that a Marshal string is identical to a constant
without loading it?
Note that Ruby doesn’t really have constants. Instead it has frozen
objects which aren’t quite the same thing.
$ ruby
A = 1
A = 1
-:2: warning: already initialized constant A
$ ruby
s = ‘’
s.freeze
s.replace ‘x’
-:3:in `replace’: can’t modify frozen string (TypeError)
from -:3
class) so
that unmarshalling a constant simply returns the already existing
constant
rather than creating a new one? I’ve noticed Fixnum’s exhibit this
behavior.
How do you know that a Marshal string is identical to a constant without
loading it?
In some cases, the identity is the name of the constant, not the value.
And that’s something that is possible to marshal consistently.
Note that Ruby doesn’t really have constants. Instead it has frozen
objects which aren’t quite the same thing.
I’m assuming the OP meant constant in the sense of binding, which ruby
does have.
Explain. I don’t see how this is true unless the name is not in scope.
I’m trying to distinguish constant in the sense of
the name “A1” in the scope of A is bound to <#A :0xb7befd40>, and
this binding cannot change
from
the object <#A :0xb7befd40> is frozen, and none of its ivars can be
assigned
There’s a ruby mechanism for each of these, so I guess the OP could have
meant either, but I was guessing the former. In that case, serializing
the constant’s name may be helpful.
TypeErrors on A non-constants). I don’t understand why it works just yet.
Will examine further tonight.
I see your point. This implementation can’t marshal anonymous instances:
anonymous = A.new
Marshal.dump(anonymous) # ==> type error
One way around this is to subclass (instances of the subclass are the
only ones that can be assigned to constants), but that may not be
acceptable to you.
def _dump(limit)
self.class.name_for_constant(self)
end
def self._load(str)
const_get str
end
end
before = AConstant::A1
after = Marshal.load(Marshal.dump(before))
puts before == after
puts before.object_id == after.object_id
anonymous = A.new
p Marshal.load(Marshal.dump(anonymous))
It would be better to put some logic in the _dump and _load methods to
handle the two cases in one class. The problem is that there is no way
to call “super” in _dump to handle the case of anonymous objects, which
should be dumped in the “normal” way. This is unfortunately the way
marshalling is structured in ruby…
Note that Ruby doesn’t really have constants. Instead it has frozen
objects which aren’t quite the same thing.
I’m assuming the OP meant constant in the sense of binding, which ruby
does have.
Yes. I did mean constant in the sense of binding to a name, as opposed
to
the immutable/frozen sense.
I too attempted revising _dump to handle things normally when objects
are
not bound to a constant name but there appears not be a ‘super’ method
to
accomplish that.
def _dump(limit)
x = self.class.name_for_constant(self)
x.nil? ? super : x # produces error: no superclass method
`_dump’
(NoMethodError)
end
Brian
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.