Re: Array#values_at bug?

[e-mail] wrote:
>> Do folks depend on this kind of behavior? I'll need to add a special
>> case to my string implementation to replicate this behavior in
>> IronRuby. Or should I do the correct thing and make "foo"[3,0] ==
>> nil?
> 
> The slippery slope :-)  I admit I'm a compatability fan, even for
> corner cases (though not for bugs, so obviously if Matz rules it a bug
> that's a different matter).

I know it's going to be tempting to fix things that feel inconsistent 
(or *are* inconsistent) but you need to decide what your primary goal 
is. If you want to run apps...you need the inconsistencies in place. 
They don't necessarily get used a lot, but they do get used. People have 
worked around many inconsistencies to such extent that fixing the 
inconsistencies may break code. It's also hard to know whether it's 
inconsistent accidentally or purposefully. Matz and Ruby old-timers will 
know best.

When in doubt, note the inconsistency, ask about it, and then implement 
it as is. That's the path to getting real apps running.

For this specific case, consider that "" is 'true' and nil is false. It 
would not be difficult to imagine someone using this output to determine 
whether we've read past the end of a string.

For my method() "bug" posted yesterday, even though I'm convinced it's a 
bug and can't imagine anyone wanting that behavior...we've implemented 
it in JRuby because someone had code that broke from "fixing" it. That 
code arguably is working around the bug, but it demonstrates the 
challenge of changing even inconsistencies when the goal is to run 
existing applications and code. We'll "fix" it when/if MRI decides to do 
the same.

- Charlie