Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: Oppinions on RCR for dup on immutable classes"
>     on Fri, 16 Feb 2007 08:55:12 +0900, "Phrogz" <gavin / refinery.com> 
> writes:
> 
> |That's a statement of fact, but doesn't explain *why* it's a problem,
> |or (important for an RCR) why it needs to be fixed in the core of the
> |language.
> |
> |What is the use case that is prevented by the problem? What does it
> |make inconvenient? Why should it be changed?
> 
> 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.
> 
>               matz.

That's why I have 2 suggestions. The issue arises when you don't know 
what you dup.
Under the aspect that obj.object_id should always be == 
obj.dup.object_id the first suggestion
of removing dup from those classes would be more appropriate.
To me it seems inconsequential to implement a method with it only 
raising an Exception.
That makes it impossible to check if your object doesn't actually 
implement dup (e.g. via
respond_to?). To me it seems that it should either be an implementation 
detail that
those classes can't really be duped (ie. return self) or expose that 
transparently (not implement dup).
That of course is my personal oppinion and I'm posting this on the ML to 
see if it is only me :)

My regards.

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