Marshal and allocating objects

[Stephen Sykes]

I would find it useful if Marshal were to use "allocate" to generate
new objects. This is so that I can load unknown objects by doing
something like this:

class Object
def self.const_missing(name)
const_set(name, kl = Class.new)
kl
end
end

And then be able to load objects with marshal without getting
ArgumentError: undefined class/module.

For example (after running the above code)...

irb(main):026:0> M.allocate
=> #<M:0x2bb2168>

That works ok, but...

irb(main):029:0> Marshal.load("\004\010o:\006N\000")
ArgumentError: undefined class/module N
from (irb):29:in `load'
from (irb):29
from (null):0

If Mashal used allocate, and hence called const_missing, then the load
would not fail. Sound reasonable?

Stephen Sykes

 

[Paul Brannan]

I would find it useful if Marshal were to use "allocate" to generate
new objects.

It does use allocate, for objects of type T_DATA (objects created from C
extensions).

This is so that I can load unknown objects by doing something like
this:

class Object
def self.const_missing(name)
const_set(name, kl = Class.new)
kl
end
end

And then be able to load objects with marshal without getting
ArgumentError: undefined class/module.

Even if allocate is used, this won't work. The lookup for the class is
failing before allocate is called.

For example (after running the above code)...

irb(main):026:0> M.allocate
=> #<M:0x2bb2168>

That works ok, but...

irb(main):029:0> Marshal.load("\004\010o:\006N\000")
ArgumentError: undefined class/module N
from (irb):29:in `load'
from (irb):29
from (null):0

If Mashal used allocate, and hence called const_missing, then the load
would not fail. Sound reasonable?

I don't like your solution, since now if I write:

class Foo
SOME_CONSTANT = 1
def foo
return SOME_CONSTATN
end
end

my code will no longer break, but will silently do the wrong thing.

Arguably better would be a callback for when Marshal.load cannot find
the class it needs. I say arguably because there really is no good way
to create a class with the correct behavior unless you already know
something about the class.

Paul

 

[ts]

P> Even if allocate is used, this won't work. The lookup for the class is
P> failing before allocate is called.

Well, if I've well understood he want that Marshal use the same algorithm
than ruby when it find a constant name.

Actually marshal just look is the constant is defined, when ruby can call
#const_missing when he write `M.allocate'

P> class Foo
P> SOME_CONSTANT = 1
P> def foo
P> return SOME_CONSTATN
P> end
P> end

P> my code will no longer break, but will silently do the wrong thing.

Not understood, sorry


Guy Decoux

 

[Paul Brannan]

P> Even if allocate is used, this won't work. The lookup for the class is
P> failing before allocate is called.

Well, if I've well understood he want that Marshal use the same algorithm
than ruby when it find a constant name.

That's the way I read it.

Actually marshal just look is the constant is defined, when ruby can call
#const_missing when he write `M.allocate'

Right, which is why const_missing never gets called. Making Ruby call
allocate doesn't solve the problem, because Ruby is checking to see if
the constant exists (in rb_path2name) before trying to look it up.

P> class Foo
P> SOME_CONSTANT = 1
P> def foo
P> return SOME_CONSTATN
P> end
P> end

P> my code will no longer break, but will silently do the wrong thing.

Not understood, sorry

In order to demonstrate why I do not think const_missing should be
defined for class Object, I intentionally misspelled "SOME_CONSTATN".
Before const_missing was defined I would get an exception here,
whereas after Stephen's version of const_missing is in place, I will
instead get a new class. Even with well-written unit tests, finding
this misspelling can be a challenge.

Paul

 

[ts]

P> In order to demonstrate why I do not think const_missing should be
P> defined for class Object, I intentionally misspelled "SOME_CONSTATN".
P> Before const_missing was defined I would get an exception here,
P> whereas after Stephen's version of const_missing is in place, I will
P> instead get a new class. Even with well-written unit tests, finding
P> this misspelling can be a challenge.

and ???

This does not his problem where `M.allocate' work but not 'Marshal.load()'


Guy Decoux

 

[Paul Brannan]

P> In order to demonstrate why I do not think const_missing should be
P> defined for class Object, I intentionally misspelled "SOME_CONSTATN".
P> Before const_missing was defined I would get an exception here,
P> whereas after Stephen's version of const_missing is in place, I will
P> instead get a new class. Even with well-written unit tests, finding
P> this misspelling can be a challenge.

and ???

This does not his problem where `M.allocate' work but not 'Marshal.load()'

Your sentence seems to be missing a necessary verb, so I'm not sure
what you are trying to say.

All I mean to say is that using const_missing to create new classes
on-the-fly is a bad idea, imo. This is what the original poster was
trying to do. It does not mean that changing Marhsal.load to have
consistent lookup with the rest of Ruby is a bad idea.

Paul

 

[ts]

solve

P> Your sentence seems to be missing a necessary verb, so I'm not sure
P> what you are trying to say.

P> All I mean to say is that using const_missing to create new classes
P> on-the-fly is a bad idea, imo. This is what the original poster was
P> trying to do. It does not mean that changing Marhsal.load to have
P> consistent lookup with the rest of Ruby is a bad idea.

In this case, I'm agree with you


Guy Decoux

 

[Keith P Hodges]

Dear Rubists

I am looking for some paid work of any kind, perhaps using ruby.

I need to work from home because I have a commitment to care for and
be available to my friend who is sick.

Would anyone be interested in employing me?

If the work can fit with my caring commitments then I will work for
basic rate just for the flexibility and the opportunity.

many thanks in advance

Keith Hodges