Marshal and allocating objects

ruby-talk
1

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

2

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

···

On Sat, Sep 04, 2004 at 07:45:22PM +0900, Stephen Sykes wrote:

3

Even if allocate is used, this won't work. The lookup for the class is
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'

  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.

Not understood, sorry

Guy Decoux

4

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

5

> Even if allocate is used, this won't work. The lookup for the class is
> 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.

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

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

···

On Wed, Sep 08, 2004 at 11:31:04PM +0900, ts wrote:

6

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.

and ???

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

Guy Decoux

7

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

···

On Wed, Sep 08, 2004 at 11:47:48PM +0900, ts wrote:

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

and ???

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

8

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

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.

In this case, I'm agree with you :slight_smile:

Guy Decoux

···

On Wed, Sep 08, 2004 at 11:47:48PM +0900, ts wrote: