On 2/16/07, Stefan Rusterholz <apeiros / gmx.net> wrote:
> 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).

>> a = 3
=> 3
>> b = a.dup rescue a
=> 3
>> b
=> 3

What's so bad about that?