Hello all,
What does the return value of a require statement supposed to indicate? My
understanding was that 'true' meant the required library got properly
loaded.
When I open a new IRB session and type, say, "require 'builder'" I get a
false returned.
require 'builder''
=> false
However, it appears that the statement does in fact load the library (the
new classes in the library become available, etc). Why is the statement
returning false (or how can I diagnose why) and is it something to be
concerned over?
---Brian
Brian Buckley wrote:
Hello all,
What does the return value of a require statement supposed to indicate?
My
understanding was that 'true' meant the required library got properly
loaded.
When I open a new IRB session and type, say, "require 'builder'" I get a
false returned.
require 'builder''
=> false
However, it appears that the statement does in fact load the library
(the
new classes in the library become available, etc). Why is the statement
returning false (or how can I diagnose why) and is it something to be
concerned over?
A false return means the file was already in $", and so wasn't loaded again. I'm guessing that some earlier require'd file has already brought in builder.rb
If the file can't be found, and exception is raised.
Brian Buckley wrote:
Hello all,
What does the return value of a require statement supposed to indicate?
My
understanding was that 'true' meant the required library got properly
loaded.
When I open a new IRB session and type, say, "require 'builder'" I get a
false returned.
require 'builder''
=> false
However, it appears that the statement does in fact load the library
(the
new classes in the library become available, etc). Why is the statement
returning false (or how can I diagnose why) and is it something to be
concerned over?
Because Builder has that stupid autorequire attribute set in its gem
spec. When you require builder, RubyGems determines that builder isn't
in your list of available libraries, so it activates the gem and
automatically requires the file listed in the autorequire attribute
(which happens to be builder). Then RubyGems allows your original
require to take place, which requires the builder file again. But,
since builder was already autorequired, this time it returns a false.
Yes, this is a bug. Yes, it is fixed in the CVS head of RubyGems.
This is one of the (many) reasons I now believe autorequire was a
mistake. I should email the author of builder and encourage him to
remove the autorequire in the gem spec. Wait, oh, nevermind.
···
--
-- Jim Weirich
--
Posted via http://www.ruby-forum.com/\.
A false return means the file was already in $", and so wasn't loaded
again. I'm guessing that some earlier require'd file has already brought
in builder.rb
This theory does not square with the fact that the require line does seem to
load a previously unloaded library.
Builder::XmlMarkup.new # fails with a NameError
require 'builder' #returns false
Builder::XmlMarkup.new # now if works
Brian
Because Builder has that stupid autorequire attribute set in its gem
spec.
Thank you for the explanation. I stumbled across this with builder while
walking through an article about builder
(Creating XML with Ruby and Builder
) but I seem to often enough encounter what seem to be invalid 'false'
returns when requiring other libraries. Is this autocomplete problem a
problem with quite a few other gems? And does it spread easily because any
require which includes a require with that bug will also be returning
false? If so it sounds like the long and the short of it for us users of
gems is we can often (and maybe even generally should) ignor the return
value of require because it gives so many false positives. Fair statement
or overstating the bug?
Brian
Brian Buckley wrote:
A false return means the file was already in $", and so wasn't loaded
again. I'm guessing that some earlier require'd file has already
brought
in builder.rb
This theory does not square with the fact that the require line does
seem to
load a previously unloaded library.
Sorry. I failed to consider that RubyGems was possibly coming into play here.
Yes for the short answer. I have found that usually if it returns fals then things are ok. If it errors out with an exception then its not ok.
Cheers-
-Ezra
···
On Jan 5, 2006, at 3:18 PM, Brian Buckley wrote:
Because Builder has that stupid autorequire attribute set in its gem
spec.
Thank you for the explanation. I stumbled across this with builder while
walking through an article about builder
(Creating XML with Ruby and Builder
) but I seem to often enough encounter what seem to be invalid 'false'
returns when requiring other libraries. Is this autocomplete problem a
problem with quite a few other gems? And does it spread easily because any
require which includes a require with that bug will also be returning
false? If so it sounds like the long and the short of it for us users of
gems is we can often (and maybe even generally should) ignor the return
value of require because it gives so many false positives. Fair statement
or overstating the bug?
Brian