[ruby-core:17886] Re: duping the NilClass

Hi --

On Mon, 21 Jul 2008, Martin Duerst wrote:

> David A. Black wrote (and Shohei Urabe supported):
>> Hi --
>>
>> On Mon, 21 Jul 2008, Nasir Khan wrote:
>>
>>> I write a lot of hand crafted dup or clone because I want control as
>>> well as
>>> better performance than the Marshal idiom. I ended up re-opening
>>> NilClass,
>>> TrueClass and FalseClass for def dup; self; end
>>> While most of the things in Ruby are very intuitive and predictable from
>>> functional perspective, this sort of stood out.. that's all.
>>
>> I understand not wanting true.dup etc. to break things,
>
> So you agree that the current behavior just breaks things?

I'm taking people's word for it. I've never encountered it myself.

> Or do you (or somebody else) know about something that would be
> broken by changing the behavior (i.e. returning self)?
>
>
>> but it's hard
>> for me to get past the fact that true.dup doesn't return a dup of
>> true, if it's defined to return true.
>
> There are objects where a dup returns a true duplicate,
> and there are some special ones where you can duplicate
> and duplicate and it's still the same. Sometimes the
> laws of physics (or computation) are not exactly what
> they seem to be. There are some objects that you can
> duplicate and duplicate, and they just stay the same :-).
>
> Given duck typing and all, returning itself (the truest
> of true copies, so to say) seems to be the best behavior
> for dup on these objects.

I think duck typing is a separate matter from the question of the
naming of a method, though. I wouldn't want objects that can't reverse
themselves to respond to 'reverse', even for the sake of duck typing.

>> Maybe it's a case for a
>> "dangerous" dup:
>>
>>   class Object
>>     def dup!
>>       dup
>>     rescue TypeError
>>       self
>>     end
>>   end
>
> In what sense would this definition of dup(!) be dangerous?

In the sense that while dup would always return a dup, dup! would have
the extra characteristic of returning self for certain objects.

> I think I understand your analogy with other ! methods, giving
> back the same object instead of a new one, but ! methods are
> used when something is being changed, and the objects in
> question are characterized just by the fact that they can't
> be changed, so ! doesn't seem very appropriate.

But ! isn't about objects that can be changed; it's about the
"dangerous" versions of methods. Danger often takes the form of
receiver mutation, but that's still just one manifestation of the
general concept of what Matz calls "danger". See:

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist


David

-- 
Rails training from David A. Black and Ruby Power and Light:
     Intro to Ruby on Rails  July 21-24      Edison, NJ
  *  Advancing With Rails    August 18-21    Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!