Asp Forum - Oppinions on RCR for dup on immutable classes

Stefan Rusterholz

2/15/2007 11:46:00 PM

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

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

7 Answers

Gavin Kistner

2/15/2007 11:52:00 PM

On Feb 15, 4:46 pm, Stefan Rusterholz <apei...@gmx.net> wrote:
> 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?

Gregory Brown

2/17/2007 8:53:00 PM

On 2/17/07, Stefan Rusterholz <apeiros@gmx.net> wrote:
> Gregory Brown wrote:
> > the difference is in the rescue.
> >
> > rescue NoMethodError
> >
> > is not the same thing as
> >
> > rescue NotImplementedError
>
> That's getting off-topic. The error dup gives is "not possible", not
> "not implemented". Different story.
> If you check previous messages you might figure that I can understand
> the use in abstract classes (or mixins here) even though I'd do it
> differently.

Actually, My point was about expressiveness through exceptions.
That is what you seem to be missing

>> 3.dup
TypeError: can't dup Fixnum
from (irb):1:in `dup'
from (irb):1

TypeError is different than NoMethodError. In this case, it is
expressive of what is actually going wrong. Again, the difference is
in the rescue.

Greg Hurrell

2/18/2007 11:33:00 AM

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

SonOfLilit

2/18/2007 12:17:00 PM

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

Marcello Barnaba

2/18/2007 12:55:00 PM

Hi,

On Sunday 18 February 2007 13:16, SonOfLilit wrote:
> 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? :)

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

SonOfLilit

2/18/2007 1:22:00 PM

On 2/18/07, Marcello Barnaba <bofh@softmedia.info> wrote:
> Hi,
>
> On Sunday 18 February 2007 13:16, SonOfLilit wrote:
> > 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? :)
>

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

dblack

2/18/2007 6:11:00 PM

comp.lang.ruby

Oppinions on RCR for dup on immutable classes

Stefan Rusterholz

Gavin Kistner

Gregory Brown

Greg Hurrell

SonOfLilit

Marcello Barnaba

SonOfLilit

dblack

x Login to ForumsZone