Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: Oppinions on RCR for dup on immutable classes"
>     on Sat, 17 Feb 2007 01:45:17 +0900, Stefan Rusterholz 
> <apeiros / gmx.net> writes:
> 
> |> Seconded.  It pretty trivial for us core developers to make dup for
> |> immutable objects to return themselves, but _I_ don't understand why
> |> it is needed.  I assume obj.object_id != obj.dup.object_id, and see no
> |> good reason enough to break the assumption.
> 
> |That's why I have 2 suggestions. The issue arises when you don't know 
> |what you dup.
> 
> But your other suggestion was just removing dup altogether, right?  In
> that case, I see no fundamental difference from the current behavior
> that raises TypeError with message "can't dup" rather than
> NoMethodError.  Exception handling is your friend.
> 
>               matz.

With current implementation, the only way to figure if an object can be 
dup'ed is by dup it and catch the exception. I don't know how imperative 
duck-typing is for ruby, but this way actively prohibits it.
The method signature of those classes suggests it can be dup'ed, but 
"hidden" in the code it actually shows that it isn't. That's in my 
oppinion intransparent.
As said before, the issue can be worked around (as you say e.g. via 
exception handling), but following your argument, my question would be: 
why implement a method that can't be executed?
I'll restate again, that I consider it a minor issue. But I thought with 
ruby2 and the cleanup of the APIs I thought it might be worth pointing.

My regards

-- 
Posted via http://www.ruby-forum.com/.