gt; Date: Saturday, March 25, 2006 7:34 am
> Subject: Re: [Jruby-devel] Bug 1121928 Patch
> To: [email protected]
>
> > FIXED! RubyGlobals was passing null in to newHash for
> > defaultValue...whichis bad! I fixed that instance and added an
> > assertion in new
.
/O
- Original Message -
From: Charles O Nutter <[EMAIL PROTECTED]>
Date: Saturday, March 25, 2006 7:34 am
Subject: Re: [Jruby-devel] Bug 1121928 Patch
To: [email protected]
> FIXED! RubyGlobals was passing null in to newHash for
> defaultValue...whichis bad!
FIXED! RubyGlobals was passing null in to newHash for defaultValue...which is bad! I fixed that instance and added an assertion in newHash to prevent it in the future.I can now run RubyGems up to the same initialize_copy error, which I'll dig into next...I suspect it's not going to be terribly pret
The new Hash#default patch appears to be broken:puts ENV('BOGUS').. blows up with an NPE. I think it has to do with calling default via RubyObject.callMethod...there's a null coming back from there, methinks. I'll see what I can find.
On 3/24/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
I sooo b
I sooo bungled the explanation in that bug that I must apologize in
the first sentence. :)
Your patch fixed some problems, but not the one represented by my ether-
sniffing-induced code sample in the bug report. What I meant to put
in that bug was something along the lines of:
h = Hash.new
Here's a patch to solve bug 1121928. With this patch Hash#default now
respects any block you set for the default and supports code like:
h = Hash.new {|h,k| h[k] = k.to_i*10}
puts h[2] # => 20
puts h.default # => 0
puts h.default(2) # => 20
Note that I also had to modify HashMetaClass so Hash#
