[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 2:21:00 PM

Hi,

In message "Re: Oppinions on RCR for dup on immutable classes"
on Sat, 17 Feb 2007 22:51:06 +0900, Stefan Rusterholz <apeiros@gmx.net> writes:

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

As far as I understand, DuckTyping is not something based on method
existence, but something letting them raise error without explicit
type checking.

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

We haven't implemented a method that can't be executed. Object#dup
just fails if the object is not able to be duped. Am I missing
something?

matz.
16 Answers

Dean Wampler

2/17/2007 3:15:00 PM

0

On 2/17/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: Oppinions on RCR for dup on immutable classes"
> on Sat, 17 Feb 2007 22:51:06 +0900, Stefan Rusterholz <apeiros@gmx.net> writes:
>
> |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.
>
> As far as I understand, DuckTyping is not something based on method
> existence, but something letting them raise error without explicit
> type checking.
>
> |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?
>
> We haven't implemented a method that can't be executed. Object#dup
> just fails if the object is not able to be duped. Am I missing
> something?
>
> matz.

For me, this does break the POLS, because it breaks the Liskov
Substitution Principle (loosely, "an object of a derived type can be
substituted for an object of a base type", for those of you who
haven't heard of it...). LSP is essentially the underpinnings of
Bertrand Meyer's "Design by Contract".

If I'm iterating through a collection of objects and all of them
respond_to? a method, yet an exception is thrown in some cases, that's
surprising ;) The deep-copy scenario is a good one. In this case, it
would be nice to have a succinct way of copying the object graph
without having to worry about some dup methods "not working". Perhaps
the "another" method suggestion would work. Perhaps thinking through
all the scenarios of why you would dup an object would suggest
refinements to its behavior. Off hand, I'm wondering if it would be so
bad for an immutable object, like a Fixnum, to allow a.object_id? ==
a.dup.object_id?.

I'm probably missing some important points, as I don't know the
intricasies of Ruby as well as many of you do. This is a typical
dilemma with rich base classes and modules. Occasionally, the rich
"contract" can't be satisfied transparently by all derivatives. Maybe
that's just the price we have to pay for being rich ;)

Dean Wampler
http://www.object...
http://www.aspectprogr...
http://www.cont...

Gregory Brown

2/17/2007 3:20:00 PM

0

On 2/17/07, Dean Wampler <deanwampler@gmail.com> wrote:

> I'm probably missing some important points, as I don't know the
> intricasies of Ruby as well as many of you do.

POLS when applied to Ruby refers to Matz's surprise. In this thread
and others, we need to remind people of that. Ruby is easy to
change, for your own needs. Feel free :)

Stefan Rusterholz

2/17/2007 3:55:00 PM

0

Yukihiro Matsumoto wrote:
> As far as I understand, DuckTyping is not something based on method
> existence, but something letting them raise error without explicit
> type checking.

Hm, we probably have a different understanding of DuckTyping then.

> We haven't implemented a method that can't be executed. Object#dup
> just fails if the object is not able to be duped. Am I missing
> something?
>
> matz.

I'll try to explain it differently, depict my issue. Say you go to a
restaurant, take a look at the card and see "Spagetthi". You order
Spagetthi but the waiter just tells you "Oh, we don't serve Spagetthi
here.". You'd naturally ask "Why put it on the card then if you don't
serve it at all?"

My regards

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

Robert Dober

2/17/2007 4:22:00 PM

0

On 2/17/07, Dean Wampler <deanwampler@gmail.com> wrote:
> On 2/17/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> > Hi,
> >
> > In message "Re: Oppinions on RCR for dup on immutable classes"
> > on Sat, 17 Feb 2007 22:51:06 +0900, Stefan Rusterholz <apeiros@gmx.net> writes:
> >
> > |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.
> >
> > As far as I understand, DuckTyping is not something based on method
> > existence, but something letting them raise error without explicit
> > type checking.
> >
> > |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?
> >
> > We haven't implemented a method that can't be executed. Object#dup
> > just fails if the object is not able to be duped. Am I missing
> > something?
> >
> > matz.
>
> For me, this does break the POLS, because it breaks the Liskov
> Substitution Principle
you are opening a can of worms (or ducks if you prefer).

I would say that LSP does not apply here simply because in Ruby we do
not have that kind of contract.
In order to apply LSP we need to say at at a point hey here we have an
object of class Base.(let the gods forgive me that I use Java)
void aMethod(final Base b){
....
}
and we expect this to work whenever we call aMethod with an object
that is a Base.
Anyway the compiler would not really allow otherwise.

SubClass sc; // subclassing Base od course
aMethod( sc ); // this is expected to work (from the type POV).

Such things just do not exist in Ruby, I believe that Ruby has
explained something to me:

OO Languages are Class oriented languages
Dynamic Languages are Object oriented languages.
Replace Class with Type and you see what I mean.

This is all very much IMHO of course but I feel that the Ruby
community has made me evolve a lot away from "Class oriented".


(loosely, "an object of a derived type can be
> substituted for an object of a base type", for those of you who
> haven't heard of it...). LSP is essentially the underpinnings of
> Bertrand Meyer's "Design by Contract".
>
> If I'm iterating through a collection of objects and all of them
> respond_to? a method, yet an exception is thrown in some cases, that's
> surprising ;)

Do not let *your* code surprise *you*. If it does than it is not the
language's fault.
But I have seen the smiley ;)

>The deep-copy scenario is a good one. In this case, it
> would be nice to have a succinct way of copying the object graph
> without having to worry about some dup methods "not working".

Meaning not worrying about the semantics of your program ???
But you still have a good use case below, not good enough for a RCR but
good. --> see my last point too please.

> Perhaps
> the "another" method suggestion would work. Perhaps thinking through
> all the scenarios of why you would dup an object would suggest
> refinements to its behavior. Off hand, I'm wondering if it would be so
> bad for an immutable object, like a Fixnum, to allow a.object_id? ==
> a.dup.object_id?.
>
> I'm probably missing some important points, as I don't know the
> intricasies of Ruby as well as many of you do. This is a typical
> dilemma with rich base classes and modules. Occasionally, the rich
> "contract" can't be satisfied transparently by all derivatives. Maybe
> that's just the price we have to pay for being rich ;)

Instead of advocating for a RCR especially in the present scenario which is:
"Well that might be bad sometimes and goos sometimes, not really worth a CR"
you might just create your own little toolbox.
class Integer ... def dup etc.

Advocating is a good thing but it is not the only one.
After some months of using your toolbox you might still want the CR or
maybe throw it away, who knows?

Cheers
Robert

P.S.
I am against the CR but the discussion is a great one! Thumbs up!
R.
>
> Dean Wampler
> http://www.object...
> http://www.aspectprogr...
> http://www.cont...
>
>


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

Ara.T.Howard

2/17/2007 4:46:00 PM

0

Dean Wampler

2/17/2007 8:09:00 PM

0

> ...
>
> OO Languages are Class oriented languages
> Dynamic Languages are Object oriented languages.
> Replace Class with Type and you see what I mean.
>
> This is all very much IMHO of course but I feel that the Ruby
> community has made me evolve a lot away from "Class oriented".

Interesting points, especially about the implications of
"class-centric" vs. "object-centric" programming.

It's true that I rarely ever run into LSP issues, even in Java code. I
think it reflects, in part, the general movement OOD towards
de-emphasizing inheritance in favor of composition through
abstractions, etc. I would rather have the richness of Object and
Kernel, even with some LSP issues.

As someone else commented, perhaps the real issue is that
5.respond_to?(:dup) returns true yet 5.dup raises, so you have no way
of knowing in advance that you shouldn't call dup.

> ...

Ara.T.Howard

2/17/2007 8:18:00 PM

0

Ara.T.Howard

2/17/2007 8:28:00 PM

0

Gregory Brown

2/17/2007 9:06:00 PM

0

On 2/17/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> one cannot
> know in advance whether it's ok to call something - even if the object
> responds to it.

With this in mind, what do you guys think of this work around?

>> [sandal@metta payroll_camping]$ irb
>> class Object
>> def dup?
>> dup
>> rescue TypeError
>> false
>> end
>> end
=> nil
>> 3.dup?
=> false
>> 3.dup? || 3
=> 3
>> "foo".dup?
=> "foo"

Ara.T.Howard

2/17/2007 9:17:00 PM

0