Oppinions on RCR for dup on immutable classes

I'm about to make this RCR and would like to get some oppinions on it in
order to make my decision.
The questions are:
1) Should I split this RCR up for a) and b)?
2) Should I only submit a single one, if so, which one?
3) Should I submit this RCR at all?
4) Oppinions, suggestions, ideas... everything welcome :slight_smile:

Abstract:
  Change behaviour of dup in immutable classes.

Problem:
  dup on immutable classes (NilClass, FalseClass, TrueClass, Fixnum,
Symbol)
  raises an Exception.

Proposal:
  a) Remove the dup method from NilClass, FalseClass, TrueClass, Fixnum,
Symbol
  b) Let dup in NilClass, FalseClass, TrueClass, Fixnum, Symbol return
self

Analysis:
  This may be a minor glitch in the ruby API, but with the advent or
Ruby2 it
  might be worth changing.
  a) should only in rare circumstances break existing code as dup for
the cases
  in question already throws an exception and it would only break if the
rescue
  would fail due to the changed exception class. It would restore the
behaviour
  that a class only implements methods it can actually execute, which
also means
  testing via respond_to? is possible.
  b) would let the immutability of the classes be an implementation
detail (which
  would be consistent with behaviour of other immutable classes like
Time e.g.).
  It shouldn't break existing code as the it is the usual fallback.

Implementation:
  a)
  [NilClass, FalseClass, TrueClass, Fixnum, Symbol].each { |klass|
    klass.send(:undef_method, :dup) { self }
  }
  b)
  [NilClass, FalseClass, TrueClass, Fixnum, Symbol].each { |klass|
    klass.send(:define_method, :dup) { self }
  }

My regards

···

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

1) Should I split this RCR up for a) and b)?
2) Should I only submit a single one, if so, which one?

You should only submit one. The discussion of which choice is better
is appropriate on the mailing list, IMO. When you feel that a
consensus has been reached, submit that one as an RCR.

Personally, I would lean towards option (b).

Problem:
  dup on immutable classes (NilClass, FalseClass, TrueClass, Fixnum,
Symbol)
  raises an Exception.

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?

···

On Feb 15, 4:46 pm, Stefan Rusterholz <apei...@gmx.net> wrote:

I personally would like to see immutable objects like Nil and Fixnum
return self if sent a dup message.

The problem with the currently model is that it makes it difficult for
the programmer to make a distinction between "by copy" ("by value")
and "by reference". The most obvious example to look at is instance
variables.

There are some cases where you want your instance variables to be set
"by reference"; that is, where you are interested in a particular,
specific object and want to keep track of it, including changes in its
value, over time. Most often the kind of object you want to pass in by
reference is a high-level object that encapsulates some kind of
complex state and behaviour.

There are also cases where you want your instance variables to be set
"by copy"; that is, where you are not concerned about the identity of
an object and only care about the value of the object at the time you
assign it to a variable. Most commonly the kinds of objects you'll
want to pass by copy are simple, primitive objects, usually numbers,
strings and values like nil.

The trouble is not that Ruby passes everything "by reference" by
default, but that Ruby makes it hard for you to pass "by copy" ("by
value") when you want to. Imagine an instance variable for which
you've defined an accessor using "attr_accessor". By default this will
pass "by reference".

If you want to pass "by copy" you have to manually write an accessor.
But if you write your accessor like this:

def my_var=(value)
  @my_var = value.dup
end

You'll get exceptions whenever you pass nil (a very common case, I
would imagine). Change it to this:

def my_var=(value)
  @my_var = (value.respond_to? :dup ? value.dup : value)
end

This works for nil, but it's not as readable because of the extra
punctuation. Try passing in a Fixnum though; you'll get an exception
because Fixnum claims to respond to "dup" but complains when you
actually send the message (pretty surprising). So you have to do this:

def my_var=(value)
  @my_var = value.dup rescue value
end

To me this seems like an awful lot of work every time you want an
instance variable to be "by copy" ("by value") instead of "by
reference". Yes, you'll might have problems here if you pass in a
singleton-but-mutable object, but I assume that if you know enough
about what you're doing to specifically want things to be passed in
"by copy" ("by value") then you also know exactly what will happen
when try passing in a singleton-but-mutable object.

As a programmer coming from Objective-C one of the current behaviour
was one the most annoying things about Ruby. Now I just write my
accessors using "rescue" whenever I want "by copy" behaviour. I
probably wouldn't have had to adopt this habit if classes like Nil and
Fixnum just returned self in response to the "dup" message. This is
the orthodox behaviour in Objective-C; in fact, even singleton-but-
mutable classes normally just return self if sent the "copy" message.

An even more elegant solution, however, would be to extend
"attr_accessor" and friends to allow the programmer to specify if
attributes should be set "by copy" or "by reference". This is exactly
what the new Obejctive-C 2.0 provides. In those cases where you want
to override the default behaviour you would do a
"attr_accessor_bycopy :my_var" and Ruby would do the right thing. Of
course, there is nothing stopping me from writing my very own
"attr_accessor_bycopy" method, but it would be nice if it were a
feature of Ruby itself.

Cheers,
Greg

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.

Say, why not just define Object#mutable? and solve the issue of not
knowing if dup is possible or not?

Sure, it only works to tell you about one possible reason it's not,
but it seems like a good workaround, far better than, say, duping just
to check.

Aur Saraf

Hi --

I personally would like to see immutable objects like Nil and Fixnum
return self if sent a dup message.

The problem with the currently model is that it makes it difficult for
the programmer to make a distinction between "by copy" ("by value")
and "by reference". The most obvious example to look at is instance
variables.

There are some cases where you want your instance variables to be set
"by reference"; that is, where you are interested in a particular,
specific object and want to keep track of it, including changes in its
value, over time. Most often the kind of object you want to pass in by
reference is a high-level object that encapsulates some kind of
complex state and behaviour.

There are also cases where you want your instance variables to be set
"by copy"; that is, where you are not concerned about the identity of
an object and only care about the value of the object at the time you
assign it to a variable. Most commonly the kinds of objects you'll
want to pass by copy are simple, primitive objects, usually numbers,
strings and values like nil.

The trouble is not that Ruby passes everything "by reference" by
default, but that Ruby makes it hard for you to pass "by copy" ("by
value") when you want to. Imagine an instance variable for which
you've defined an accessor using "attr_accessor". By default this will
pass "by reference".

If you want to pass "by copy" you have to manually write an accessor.
But if you write your accessor like this:

def my_var=(value)
@my_var = value.dup
end

You'll get exceptions whenever you pass nil (a very common case, I
would imagine). Change it to this:

def my_var=(value)
@my_var = (value.respond_to? :dup ? value.dup : value)
end

This works for nil, but it's not as readable because of the extra
punctuation. Try passing in a Fixnum though; you'll get an exception
because Fixnum claims to respond to "dup" but complains when you
actually send the message (pretty surprising). So you have to do this:

def my_var=(value)
@my_var = value.dup rescue value
end

To me this seems like an awful lot of work every time you want an
instance variable to be "by copy" ("by value") instead of "by
reference". Yes, you'll might have problems here if you pass in a
singleton-but-mutable object, but I assume that if you know enough
about what you're doing to specifically want things to be passed in
"by copy" ("by value") then you also know exactly what will happen
when try passing in a singleton-but-mutable object.

As a programmer coming from Objective-C one of the current behaviour
was one the most annoying things about Ruby. Now I just write my
accessors using "rescue" whenever I want "by copy" behaviour. I
probably wouldn't have had to adopt this habit if classes like Nil and
Fixnum just returned self in response to the "dup" message. This is
the orthodox behaviour in Objective-C; in fact, even singleton-but-
mutable classes normally just return self if sent the "copy" message.

An even more elegant solution, however, would be to extend
"attr_accessor" and friends to allow the programmer to specify if
attributes should be set "by copy" or "by reference". This is exactly
what the new Obejctive-C 2.0 provides. In those cases where you want
to override the default behaviour you would do a
"attr_accessor_bycopy :my_var" and Ruby would do the right thing. Of
course, there is nothing stopping me from writing my very own
"attr_accessor_bycopy" method, but it would be nice if it were a
feature of Ruby itself.

One problem with this is that dup oeprations don't fall precisely
along the lines of a by value/by reference/by copy categorization. If
you do this:

   a = "hi"
   b = a.dup

you're assigning to b a reference to a dup of a. If you do this:

   b = a

you're assigning a reference (the one in a) by value to b. This stuff
won't necessarily transliterate well from another language.

I'd rather just keep what's happening on the surface: if you want a
dup of an object, then call dup on it (with error handling if
necessary). I think that's better than add a new layer of terminology
to Ruby method names. (I'm also not sold on the idea of a method
called "dup" harboring the possibility of silently returning something
that isn't a dup, as discussed earlier in the thread.)

Maybe we'll go down the road of flags some day:

   attr_reader(:dup => true)

or something....

David

···

On Sun, 18 Feb 2007, Greg Hurrell wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

+1. If i am trying to dup an object, sometimes it's inconvenient that
it complains,
but most of the time i want to know about it.

I also don't think something like 5.dup has semantic meaning.

···

On 2/16/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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.

Yukihiro Matsumoto wrote:

Hi,

>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 :slight_smile:

My regards.

···

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:

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

Hi,

Say, why not just define Object#mutable? and solve the issue of not
knowing if dup is possible or not?

In my opinion, this exposes at the ruby level an implementation detail that
pollutes the language design, and you must add it to the "weird things you
should remember".

Please, compare

def a
  obj = some_method
  raise 'hey!' unless obj.mutable?
  do_stuff obj.dup
rescue SomeMethodError
  pull_out_the_power_cord
end

to

def a
  do_stuff some_method.dup
rescue SomeMethodError
  pull_out_the_power_cord
rescue TypeError
  raise 'hey!'
end

I think that the whole design is clear and makes sense, you can call a method,
and you should catch exceptions, if you care about them. Or let them stop
execution, if needed.

Sure, it only works to tell you about one possible reason it's not,
but it seems like a good workaround, far better than, say, duping just
to check.

Why should "dup" behave differently than all the other methods that raise
exceptions when something exceptional happens? :slight_smile:

my 0.02c

···

On Sunday 18 February 2007 13:16, SonOfLilit wrote:
--
pub 1024D/8D2787EF 723C 7CA3 3C19 2ACE 6E20 9CC1 9956 EB3C 8D27 87EF

unlike 42.dup, which is patently obivous.

-a

···

On Fri, 16 Feb 2007, Gregory Brown wrote:

I also don't think something like 5.dup has semantic meaning.

--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama

Yukihiro Matsumoto wrote:
> Hi,
>
> >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?

···

On 2/16/07, Stefan Rusterholz <apeiros@gmx.net> wrote:

> 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:

Ruby is always about principle-of-least-surprise and this behavior
really surprised me when I first read about it non-list (I've stayed
away from object copies in MY code, because it all seems so hacky and
arcane to me... Truns out it was a good idea)

Actually, Ruby is about the principle-of-least-surprise-for-matz.

I used to think POLS applied to everyone when I started with Ruby.
Many people, including Matz, pointed out that it's impossible to make
things unsurprising to everyone, because people will be surprised by
different things.

Just because something is surprising to you doesn't mean that it
should be changed in Ruby. You are advised (as was I) not to use POLS
as justification for why something should be changed.

...

Having said that, I personally would prefer for 3.dup to 'just work',
returning an object that is equivalent to the original. Just because
the new instance happens to be the same doesn't mean that it's bad -
as an immutable object, the only way to tell is via object_id, anyhow.

···

From: SonOfLilit [mailto:sonoflilit@gmail.com]
Sent: Friday, February 16, 2007 10:48 AM

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.

Hi,

> Say, why not just define Object#mutable? and solve the issue of not
> knowing if dup is possible or not?

In my opinion, this exposes at the ruby level an implementation detail that
pollutes the language design, and you must add it to the "weird things you
should remember".

Please, compare

def a
  obj = some_method
  raise 'hey!' unless obj.mutable?
  do_stuff obj.dup
rescue SomeMethodError
  pull_out_the_power_cord
end

to

def a
  do_stuff some_method.dup
rescue SomeMethodError
  pull_out_the_power_cord
rescue TypeError
  raise 'hey!'
end

I think that the whole design is clear and makes sense, you can call a method,
and you should catch exceptions, if you care about them. Or let them stop
execution, if needed.

> Sure, it only works to tell you about one possible reason it's not,
> but it seems like a good workaround, far better than, say, duping just
> to check.

Why should "dup" behave differently than all the other methods that raise
exceptions when something exceptional happens? :slight_smile:

Because it's something exceptional that is very predictable and we
might want to know about it in advance.

My workaround is an addition, not a modification. For most cases,
rescue TypeError is perfectly fine, but sometimes we might want to
validate that a received object is dup-able at the beginning of a
method, before doing some hard work that would only _later_ require
duping it.

That's why I support having a way to know if oyu'll be able to dup.

my 0.02c
--
pub 1024D/8D2787EF 723C 7CA3 3C19 2ACE 6E20 9CC1 9956 EB3C 8D27 87EF

Speaking of which, why IS mutability of certain objects left as an
implementation detail? I think we assume mutability/immutability of
objects a LOT at coding time, and for a different implementation to do
otherwise would certainly have performance implications and probably
even make code written for say MRI break, isn't it so?

Perhaps mutability/immutability should be in the spec?

Aur Saraf

···

On 2/18/07, Marcello Barnaba <bofh@softmedia.info> wrote:

On Sunday 18 February 2007 13:16, SonOfLilit wrote:

When you use #dup not knowing about this complication, never dup a Fixnum in
testing, but happen to dup one in production - e.g. in a library released to
the public.

Ruby is always about principle-of-least-surprise and this behavior really
surprised me when I first read about it non-list (I've stayed away from
object copies in MY code, because it all seems so hacky and arcane to me...
Truns out it was a good idea)

···

On 2/16/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:

On 2/16/07, Stefan Rusterholz <apeiros@gmx.net> wrote:
>> a = 3
=> 3
>> b = a.dup rescue a
=> 3
>> b
=> 3

What's so bad about that?

I would ask the question: Why do you dup a?
The answer is, I presume, because I will modify the duplicate and I
do not want to modify the original.
ok so let us follow our code

b= a.dup rescue a
...

b.mutating_method
what will happen now?

Cheers
Robert

···

On 2/16/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:

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?

--
We have not succeeded in answering all of our questions.
In fact, in some ways, we are more confused than ever.
But we feel we are confused on a higher level and about more important things.
-Anonymous

Hi --

···

On Sat, 17 Feb 2007, Phrogz wrote:

From: SonOfLilit [mailto:sonoflilit@gmail.com]
Sent: Friday, February 16, 2007 10:48 AM

Ruby is always about principle-of-least-surprise and this behavior
really surprised me when I first read about it non-list (I've stayed
away from object copies in MY code, because it all seems so hacky and
arcane to me... Truns out it was a good idea)

Actually, Ruby is about the principle-of-least-surprise-for-matz.

I used to think POLS applied to everyone when I started with Ruby.
Many people, including Matz, pointed out that it's impossible to make
things unsurprising to everyone, because people will be surprised by
different things.

Just because something is surprising to you doesn't mean that it
should be changed in Ruby. You are advised (as was I) not to use POLS
as justification for why something should be changed.

...

Having said that, I personally would prefer for 3.dup to 'just work',
returning an object that is equivalent to the original. Just because
the new instance happens to be the same doesn't mean that it's bad -
as an immutable object, the only way to tell is via object_id, anyhow.

It doesn't mean it's bad, but it does mean that it isn't a duplicate
:slight_smile: At least, I wouldn't think that dup is the right name for a
method that might actually return the receiver.

David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

I've come across this situation when writing generic code to do a
'deep copy'. Instead of changing the semantics of #dup, why not have
some other method that means 'make a copy if you can but if the object
has immutable semantics then return a reference to self'.

As for a name for such a method, how about Kernel#another ?

I'm not sure how #dup, #clone, and #another should be related. Perhaps
#another should use #clone instead of #dup? Maybe there should be another
version of #another that uses clone semantics?

Gary Wright

···

On Feb 16, 2007, at 1:50 PM, Phrogz wrote:

Having said that, I personally would prefer for 3.dup to 'just work',
returning an object that is equivalent to the original. Just because
the new instance happens to be the same doesn't mean that it's bad -
as an immutable object, the only way to tell is via object_id, anyhow.

Gregory Brown wrote:

> >
That's why I have 2 suggestions. The issue arises when you don't know
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?

As I said, I consider it a minor glitch. Of course you can work around
the problem, but a workaround is still only a workaround. IMHO the
"correct" way to do what you do above would be:

b = a.respond_to?(:dup) ? a.dup : a

If you have concerns about that beeing not as fast as rescuing your code
would still work (the raised exception would just be different).
Since that is my oppinion I posted this to the ML to see what other
oppinions about that are.
Besides, your above code assumes that the only reason a dup fails is due
to the singleton-immutables, what if dup fails due to another reason?
With your above code you'll have a happy time tracking the bug as a
potential exception will never be raised.

My regards

···

On 2/16/07, Stefan Rusterholz <apeiros@gmx.net> wrote:

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

Yukihiro Matsumoto wrote:

Hi,

>> 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

···

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:

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