Closed sferik closed 10 years ago
Very cool.
Thanks for reviewing and merging this patch.
Upon re-reading my description above, I wanted to clarify one of the points:
works more consistently across different Ruby versions
What I mean by this is: the behavior of naught
will be more consistent with the Ruby environment in which it is running. I realized this sentence could be construed to mean the opposite: that naught
will behave identically across Ruby versions. This is not the case.
For example, NilClass#to_h
was only added Ruby 2.0 (after I suggested it back in 2009). Before this patch was applied, null objects with explicit conversions would define a to_h
method, even on Ruby 1.9, where nil
does not respond to to_h
. This patch ensures that null objects with explicit conversions will respond exactly like nil
on whatever Ruby environment you happen to be running.
This could result in backward-incompatibility for programs that depend on null objects responding to to_h
with {}
on Ruby 1.9. Please consider this when choosing a version number for the next release, although Semantic Versioning does not have strong prescriptions for gems that have not reached 1.0.0.
Arguably, it was a bug that null objects ever responded to to_h
on Ruby 1.9 but if you want to add back this feature, you could do as a one-off (i.e. delegate everything expect for to_h
on Ruby 1.9). The same thing could be done for to_c
and to_r
on Ruby 1.8, if I ever figure out how to make the specs pass. That said, in my opinion, such steps are unnecessary and the post-merge behavior is how it should have always worked.
Someone yelled at me for the sub-1.0 version once, but this is exactly why! These things still needed some peer-review... I'm fine with this being the new normal; it's easy enough to override the definitions in per-project Naught configurations.
This refactoring:
DefineExplicitConversions#call
(11.downto(6)
),NilClass
in future Ruby versions),nil
does vs. do this explicit thing, which happens to be whatnil
does).I've also taken this opportunity to alphabetize the method names, for organizational purposes.