Brent Dillingham
8/23/2008 4:06:00 PM
Thanks for the replies!
Botp, your "cheat" does indeed allow you to use require again to load =20=
the source file, but this is actually doing the same thing as using =20
Kernel.load. It's just interpreting the contents of foo.rb again, =20
effectively reopening class Foo. Kernel.load is just like require, =20
only require checks $LOADED_FEATURES I guess before it blindly =20
interprets the content of your file again. Kernel.load doesn't do any =20=
such check; it interprets the file you point it to no matter what.
I did try it, but unfortunately DataMapper still complains about =20
missing properties and such on existing objects after the reload. And =20=
the problem still remains that we are not truly "reloading" the =20
class ... we're just reopening it, adding or overwriting methods, just =20=
like we might in an IRB session.
I did try to go the Marshal route, but Marshal.dump chokes when trying =20=
to dump most of my objects with "TypeError: can't dump hash with =20
default proc". I don't know exactly what that's referring to (the =20
stack trace is useless), but it probably has something to do with a =20
DataMapper feature. Marshal seems to be pretty unreliable for any kind =20=
of non-trivial object, and I think doing any kind of "deep copy" on my =20=
objects will lead to weird duplication issues with their associations =20=
anyway. e.g. two Player objects in the same Room need to refer to the =20=
same object_id for player.room (at least, that's the assumption I'm =20
designing under right now to prevent hitting the DB constantly). If I =20=
do a deep copy as Marshal.dump(player) would do, I'll end up with the =20=
players referring to two brand new, different copies of Room objects. =20=
Which is bad, I think.
Though it's possible that I'm making a mistake by relying on the Room =20=
objects staying in-memory. I need to read up on how garbage collection =20=
works.
At any rate, I'm about to give up on this idea unless anyone has any =20
other suggestions. Thanks!
Brent
On Aug 23, 2008, at 12:05 AM, Pe=F1a, Botp wrote:
> From: Brent Dillingham [mailto:brentdillingham@gmail.com]
> # ...
> # >> puts File.read('foo.rb')
> # class Foo
> # def hello
> # "Hello, world!"
> # end
> # end
> # =3D> nil
> # >> require 'foo'
> # =3D> true
>
> ok. you used require
>
> # # Reload the file using remove_const and Kernel.load
> # >> Object.send(:remove_const, :Foo)
> # =3D> Foo
> # >> Kernel.load('foo.rb')
> # =3D> true
>
> now you use load.
>
> let us stick to require... ;)
>
> irb(main):001:0> require 'foo.rb'
> =3D> true89
> irb(main):002:0> f=3DFoo.new
> =3D> #<Foo:0x2900af4>
> irb(main):003:0> f.hello
> =3D> "hello"
>
> ok
>
> irb(main):004:0> require 'foo.rb'
> =3D> false
> irb(main):005:0> f.hello
> =3D> "hello"
>
> as expected, no change.
> let's see if we can cheat ;)
>
> irb(main):006:0> $LOADED_FEATURES
> =3D> ["e2mmap.rb", "irb/init.rb", "irb/workspace.rb", "irb/=20
> context.rb", "irb/extend-command.rb", "irb/output-method.rb", "irb/=20
> notifier.rb", "irb/slex.rb", "irb/ruby-token.rb", "irb/ruby-lex.rb", =20=
> "readline.so", "irb/input-method.rb", "irb/locale.rb", "irb.rb", =20
> "irb/ext/history.rb", "irb/ext/save-history.rb", "foo.rb"]
>
> ah
>
> irb(main):007:0> $LOADED_FEATURES.delete "foo.rb"
> =3D> "foo.rb"
>
> irb(main):008:0> require 'foo.rb'
> =3D> true
> irb(main):009:0> f.hello
> =3D> "new hello"
>
> is that ok?
> ... caveat, i'm not sure if that is documented/supported. maybe, =20
> verify fr matz or nobu..
>
> kind regards -botp
>
>