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.objectmentor.com
> http://www.aspectprogramming.com
> http://www.contract4j.org
>
>


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