[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Oppinions on RCR for dup on immutable classes

Yukihiro Matsumoto

2/17/2007 1:18:00 PM

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

Stefan Rusterholz

2/17/2007 1:51:00 PM

0

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

Ara.T.Howard

2/17/2007 3:04:00 PM

0

Stefan Rusterholz

2/17/2007 3:33:00 PM

0

unknown wrote:
> because, in ruby, all methods can be changed all the time:
>
> class C
> def dup() raise "now you can't" end
> end
>
> c = C.new
>
> c.dup rescue nil
>
> class << c
> def dup() raise "now you can" end
> end
>
> c.dup
>
> just because an object responded to a message one time, at compile time,
> or
> whatever - doesn't mean it will later. this is the dynamic in 'dynamic
> languages.'
>
> note that being able to dump singleton classes doesn't change this one
> bit.
>
> regards.
>
>
> -a

Care to explain why you chose defining a method with the sole purpose of
raising an exception over removing the method instead?

My regards

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

Ara.T.Howard

2/17/2007 4:42:00 PM

0

Stefan Rusterholz

2/17/2007 5:51:00 PM

0

unknown wrote:
> On Sun, 18 Feb 2007, Stefan Rusterholz wrote:
>
>> Care to explain why you chose defining a method with the sole purpose of
>> raising an exception over removing the method instead?
>
> yes - for illustration ;-)

And in a real situation, why would you chose to do so? What would be the
reasoning to justify that?

> this is a side effect of strong dynamic type systems

I am well aware of that. I used ruby for over a year ;-)
But you in this situations you have two options, define a method whichs
only code is "raise Exception" or not define the method at all.
Or in your example the choice is between redefining the method with one
whichs only code is "raise Exception" or undefine the existing one.
In both situations: why would you chose one over the other?
I'm sorry if I'm obnoxious with that :)

My regards

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

Ara.T.Howard

2/17/2007 6:42:00 PM

0

Stefan Rusterholz

2/17/2007 7:31:00 PM

0

unknown wrote:
> the one that springs to mind is
>
> module Mixin
> def average
> total.to_f / n.to_f
> end
> def total
> raise NotImplementedError
> end
> def n
> raise NotImplementedError
> end
> end
>
> this give a much nicer error than NameError or something about nil not
> responding to 'to_f'.

module Mixin
def average
total().quo(n())
end
end

a) uses Rational if possible ;-p (ok, besides the point)
b) no superfluous code
c) no additional exception

I'm sorry, I still fail to see the point in defining a method that says
the method can't be executed (put a menu that isn't actually served on
the menucard - put it on the menucard when it is served)

My regards

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

Gregory Brown

2/17/2007 7:34:00 PM

0

On 2/17/07, Stefan Rusterholz <apeiros@gmx.net> wrote:
> unknown wrote:
> > the one that springs to mind is
> >
> > module Mixin
> > def average
> > total.to_f / n.to_f
> > end
> > def total
> > raise NotImplementedError
> > end
> > def n
> > raise NotImplementedError
> > end
> > end
> >
> > this give a much nicer error than NameError or something about nil not
> > responding to 'to_f'.
>
> module Mixin
> def average
> total().quo(n())
> end
> end
>
> a) uses Rational if possible ;-p (ok, besides the point)
> b) no superfluous code
> c) no additional exception
>
> I'm sorry, I still fail to see the point in defining a method that says
> the method can't be executed (put a menu that isn't actually served on
> the menucard - put it on the menucard when it is served)

the difference is in the rescue.

rescue NoMethodError

is not the same thing as

rescue NotImplementedError

Stefan Rusterholz

2/17/2007 7:43:00 PM

0

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.

My regards.

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

td

2/2/2014 6:54:00 PM

0

On Sunday, February 2, 2014 1:09:13 PM UTC-5, JohnGavin wrote:
> On Sunday, February 2, 2014 12:50:52 PM UTC-5, td wrote:
>
> > On Sunday, February 2, 2014 12:44:14 PM UTC-5, JohnGavin wrote:
>
> >
>
> > > This new release (one of Rafael Puyana's last recordings) has not been widely publicized.
>
> >
>
> > >
>
> >
>
> > > It was done on Puyana's 3 manual Haas instrument.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > It is available on the Sanctus website:
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > http://rafaelpuyana.sanctusrecor...
>
> >
>
> >
>
> >
>
> > I must say I was unaware that he had still been making recordings, John, before his death last March.
>
> >
>
> >
>
> >
>
> > TD
>
>
>
> Yes, there's also a 2-CD Scarlatti set waiting to be released (different from the older Harmonia Mundi set).

Interesting.

His Fandango is still matchless, in my opinion. Such rhythm!

TD