From: Olivier Nenert Date: 2003-08-09T04:32:42+09:00 Subject: Re: Ducktype, right? (Hi I'm a new comer, just reading the first lines of ruby code and I'm already dazzled) > Ben Giddings wrote: > >> In Java you could check to see if something is of a certain class, but >> what was more often done was to see if something implemented a certain >> interface. Implementing an interface was a way of signalling "I declare >> myself to act like a duck". And the fact you implemented the interface >> meant that you had all the necessary features to act like a duck. You >> weren't allowed to implement the interface and then only choose certain >> duck-like features. >> >> It seems to me that duck-typing in Ruby should strive for the same >> thing. Checking for one method isn't enough, in my opinion. >> > I agree with Ryan's reply to you. If I only need the one method on the > object I'm interacting with -- should that one call not be allowed simply > because all of the other methods that I don't need aren't consistent with > what it *should* be? > I think that what Ben means isn't to replace this actual can_you_do_that? way of thinking, but to extend it, just as there's nothing wrong with your argument: "if all you need from the object is to execute this method, it doesn't matter what it is per se, as long as it does it", the idea of implementing an interface comes naturaly as an extension. (I don't program in java, so maybe what he talks about is actualy different, but that's how I understand it myself and how I wish to create my own object model). it says "I declare that I act like a duck" that doesn't mean "I am a duck", nothing prevents me from also being able to behave like an elephant or whatever, even if in the end what i realy am is a completely different object. while asking an obejct if he is able to execute a particular method is very useful, the interface idea is much more powerful *and* useful. first, the method_can_do? can lead to confusion, maybe I tell you yes I can switch on, and yes I can switch off.. so, as a general object manager-scheduler, when I fall in your grasp you say "this one I can 'pause' and run later. However, I'm part of a lightning control system, and all I do is switch lights on and off. the fact is, sooner or later, you'll have to consider that after all, even if my type isn't realy important, the can_you_do_that? idea is just as misleading, when you want me to execute this method, it's not because of the method itself, but because you want me to "behave a certain way" (like a duck) I think it's better to ask me if I can behave like a duck and then ask me to quack, then ask me if I can quack, and then make me do something totaly unrelated to the "duck quacking idea" (maybe I start "quack arena" :)). But of course, those confusions could be avoided by chosing wisely the method names (there *will* however exist collisions, that's unavoidable) and, clearly, in the very same way, a duck interface could be also confused, so the interface idea is not realy to prevent name collisions, but to show that in the end what you want is a global behavior, not just a particular action.. But the great advantage of a whole interface presentation would be for greater automated interactions between objects, you could for instance, declare an object as being this- interface-friendly and by simply asociating them, have them work automaticaly together. behind a well defined interface lie several methods but also several "receptors" we'd know how to use. I also hope ruby ducktyping goes in this direction, it would be of extreme usefulness, especialy in the case of distributed ruby where we should be able to make high level services interact intelligently with very few "duck-taping" code in between. Olivier.