I am just wondering is there any differnece between these two
techniques.
There is file.rb
1. use load to execute contents of file.rb
load "file.rb"
2. use eval to execute contents of file.rb
c = File.open('file.rb') {|f| f.read }
eval(c)
Load is more conventional but eval is more flexible (source can be
modifyed before evaluated).
Are there any hidden gotchas?
by
TheR
--
Posted via http://www.ruby-forum.com/.
Damjan Rems wrote:
I am just wondering is there any differnece between these two
techniques.
#load uses the $LOAD_PATH, just as #require does:
irb(main):001:0> load "fileutils.rb"
=> true
irb(main):002:0> FileUtils
=> FileUtils
However, #load doesn't check if something is already loaded:
irb(main):003:0> load "fileutils.rb"
/usr/local/lib/ruby/1.8/fileutils.rb:93: warning: already initialized constant OPT_TABLE
/usr/local/lib/ruby/1.8/fileutils.rb:1163: warning: already initialized constant S_IF_DOOR
/usr/local/lib/ruby/1.8/fileutils.rb:1513: warning: already initialized constant METHODS
=> true
$ qri load
------------------------------------------------------------ Kernel#load
load(filename, wrap=false) => true
------------------------------------------------------------------------
Loads and executes the Ruby program in the file _filename_. If the
filename does not resolve to an absolute path, the file is searched
for in the library directories listed in +$:+. If the optional
_wrap_ parameter is +true+, the loaded script will be executed
under an anonymous module, protecting the calling program's global
namespace. In no circumstance will any local variables in the
loaded file be propagated to the loading environment.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Damjan Rems wrote:
I am just wondering is there any differnece between these two
techniques.There is file.rb
1. use load to execute contents of file.rb
load "file.rb"2. use eval to execute contents of file.rb
c = File.open('file.rb') {|f| f.read }
eval(c)Load is more conventional but eval is more flexible (source can be
modifyed before evaluated).Are there any hidden gotchas?
by
TheR
Yes, there IS a difference, and yes, there ARE gotchas.
1. The load way:
module Alpha
load 'file.rb'
end
class Beta
load 'file.rb'
end
class Gamma
include Alpha
end
2. The eval way:
module Alpha
c = File.open('file.rb') {|f| f.read }
eval c
end
class Beta
c = File.open('file.rb') {|f| f.read }
eval c
end
class Gamma
include Alpha
end
In 1., the contents of file.rb are loaded in *global* namespace. But
that's not the whole story. When file.rb defines a method my_method,
you'll end up with *four* methods: a public main#my_method, a private
Alpha#my_method, a private Beta#my_method and a private Gamma#my_method.
Not quite a "least surprise".
2.'s behaviour is more intuitive. You'll get a public Alpha#my_method, a
public Beta#my_method and a public Gamma#my_method. But if file.rb has
any load (or require) of its own, that stuff will be loaded in your
script's global namespace...
And there's my problem. I'm using two different libraries both
containing (directly or indirectly) modules or classes with the same
name. To avoid name conflicts, I would like my script to wrap them (or
at least one of them) in their own namespace. But such a thing seems to
be impossible if those modules/classes are placed far away in a long
chain of required libraries. Is there any way out of this library hell?
--
Posted via http://www.ruby-forum.com/\.
Meindert Meindertsma wrote:
...
And there's my problem. I'm using two different libraries both
containing (directly or indirectly) modules or classes with the same
name. To avoid name conflicts, I would like my script to wrap them (or
at least one of them) in their own namespace. But such a thing seems to
be impossible if those modules/classes are placed far away in a long
chain of required libraries. Is there any way out of this library hell?
Found this one in another thread:
Moreover, there is already brilliant Script[1] library, which allows to
do such kind of things right now.
1. Script
--
Posted via http://www.ruby-forum.com/\.