«

Hi --

On Mon, 24 Jul 2006, Alex Young wrote:

> If you're always supplying Duck's functionality as a mixin, you can do:
>
> Duck === d
> => true
>
> The beauty of duck-typing is that you don't have to, though.

I'd go further: the definition of duck typing is that you don't

I think Dave Thomas was always pretty explicit about saying that duck
typing, in practice as well as theory, is something one does *instead*
of checking class/module ancestry. I think the use of Duck, duck,
quack, etc. as class and method names is kind of misleading. It moves
the class-checking approach into the "duck" namespace -- which means
that "duck typing" gets redefined, and it also means that the thing
originally called "duck typing" is left without a name.

What it always comes down to for me is this: in Ruby, at the moment
that you send a message to an object, you send a message to an object.
No amount of checking of class membership -- not even, technically,
the prior checking of respond_to? -- has any bearing on what happens
when that message is sent.

Duck typing is Dave's name for an approach to Ruby programming that
attempts to live in harmony with this underlying state of things in
Ruby, rather than covering it up or pretending it isn't there.

There are two major ramifications of duck typing:

1. it leads you to understand what's actually happening every
time you call a method in Ruby;
2. it points the way to interesting and productive things you
can do to harness the way Ruby works, rather than fighting it.

I've always agreed with Jim Weirich that Ruby is "a duck-typed
language". In other words, as far as Ruby is concerned, everyone is
duck typing: everyone is sending messages to objects, and those
message-sending events are never connected directly to an object's
ancestry. Hence #1 in the list above.

As for #2 -- it's not that it's a mark of shame to use #is_a? and
#respond_to?, but rather that Ruby does provide a programming
environment in which it's possible, thanks to a design that eschews
certain constraints, to do otherwise, with good results.

Final note to Alex: much of what's here is in response to the whole
thread, even though it's in a response to your post


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
=> me

On Jul 23, 2006, at 10:59 PM, Jake McArthur wrote:

> I much prefer its (less mature) derivative, Io. Everything is a
> message to something else, and everything is a prototype. Very
> simple, very powerful (even, dare I say, more powerful than Ruby,
> albeit a bit less pretty).
>
> - Jake McArthur

You piqued my curiosity with that. But "lo" is really hard to google
for. Do you have any reference links?
-Mat

Robert Dober wrote:
<snip>
> Maybe we can fly. Maybe. But I do not believe so.
> It just strikes me as if the community is throwing away so much by being,
> forgive me to be blunt, intolerant about philosophies that are well known,
> like early failing.
> Although I said intolerant I want to add immediately that they are nicely
> so, but quite firmely.
Duck typing doesn't stop you from failing early. If you combine the
#implements? method with the monitor-functions example from earlier in
the thread, you've got quite a nice interface checker.

You can have your duck and eat it too.

--
Alex

> You piqued my curiosity with that. But "lo" is really hard to google
> for. Do you have any reference links?

Actually it is pretty easy to google: Io programming language

http://www.iolanguage.com/about/


Regards,
Rimantas
--
http://rimantas.com/

Mat Schaffer wrote:
>
> On Jul 23, 2006, at 10:59 PM, Jake McArthur wrote:
>
>> I much prefer its (less mature) derivative, Io. Everything is a
>> message to something else, and everything is a prototype. Very
>> simple, very powerful (even, dare I say, more powerful than Ruby,
>> albeit a bit less pretty).
>>
>> - Jake McArthur
>
>
> You piqued my curiosity with that. But "lo" is really hard to google
> for. Do you have any reference links?
http://www.iolanguage.com/about/

--
Alex

On Jul 24, 2006, at 8:52 AM, Rimantas Liubertas wrote:

>> You piqued my curiosity with that. But "lo" is really hard to google
>> for. Do you have any reference links?
>
> Actually it is pretty easy to google: Io programming language
>
> http://www.iolanguage.com/about/

Right. io, not LO..... silly sans-serif fonts.
Thanks!
-Mat

Hi --

On Mon, 24 Jul 2006, Robert Dober wrote:

> On 7/24/06, Alex Young <> wrote:
>>
>> Robert Dober wrote:
>> <snip>
>> > Maybe we can fly. Maybe. But I do not believe so.
>> > It just strikes me as if the community is throwing away so much by
>> being,
>> > forgive me to be blunt, intolerant about philosophies that are well
>> known,
>> > like early failing.
>> > Although I said intolerant I want to add immediately that they are
>> nicely
>> > so, but quite firmely.
>> Duck typing doesn't stop you from failing early. If you combine the
>> #implements? method with the monitor-functions example from earlier in
>> the thread, you've got quite a nice interface checker.
>>
>> You can have your duck and eat it too.
>
>
> Nice 1.
>
> --
>> Alex
>>
>>
> Ah sorry I had the impression some are fairly opposed to that approach and
> considered it unrubyfull. Maybe I am too *sensible*.

I don't think I'd call interface-checking "duck typing", but if it
helps you build the program you want, then you should probably do it.


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
=> me

> You piqued my curiosity with that. But "lo" is really hard to google
> for. Do you have any reference links?
> -Mat

http://www.iolanguage.com/

Enjoy

--
Fabio Aquotte

wrote:
> I also like it because I don't think that there's anything especially
> fundamental about classes. With predicate classes, all you're really
> saying is that "if I've got something that can do x and y, then I know
> that I can equally validly think of it as something that can do z".

The concept really piqued my interest, and since ruby gives us such nice
metaprogramming abilities, why not do it?


module DuckTyping
@@quacks = Hash.new{ |h,k| h[k] = {} }

def ducktype(*reqs, &block)
o = Object
before = o.methods
o.class_eval(&block)
after = o.methods

for methodname in (after - before)
@@quacks[methodname.to_sym][reqs] = o.instance_method(methodname.to_sym)
o.send(:remove_method, methodname.to_sym)
end
end

def ducktype_method(methodname)
@@quacks[methodname.to_sym].each do |reqs, m|
if reqs.all?{ |r| self.respond_to?(r) }
return m
end
end
return nil
end

def method_missing(methodname, *args, &block)
if m = ducktype_method(methodname)
m.bind(self).call(*args, &block)
else
super
end
end
end
Object.module_eval{ include DuckTyping }


ducktype :quack do
def quack_loudly
quack.upcase
end
end


class Duck
def quack
"quack!"
end
end

class Dog
def bark
"woof!"
end
end

Duck.new.quack_loudly #=> "QUACK!"
Dog.new.quack_loudly #=> NoMethodError


nifty?

Daniel DeLorme wrote:
> wrote:
> > I also like it because I don't think that there's anything especially
> > fundamental about classes. With predicate classes, all you're really
> > saying is that "if I've got something that can do x and y, then I know
> > that I can equally validly think of it as something that can do z".
>
> The concept really piqued my interest, and since ruby gives us such nice
> metaprogramming abilities, why not do it?
>
> module DuckTyping
> @@quacks = Hash.new{ |h,k| h[k] = {} }

[snip cool code]

> ducktype :quack do
> def quack_loudly
> quack.upcase
> end
> end
>
>
> class Duck
> def quack
> "quack!"
> end
> end
>
> class Dog
> def bark
> "woof!"
> end
> end
>
> Duck.new.quack_loudly #=> "QUACK!"
> Dog.new.quack_loudly #=> NoMethodError
>
>
> nifty?

Nicely done! Code worthy of experimentation. A lot of excellent
comments in this thread too.

I wonder then, if we take up John Carter's notion on duck as mixin,
then Enumerable can be defined as:

ducktype :each do
def collect
each{ |e| yield(e) }
end
...
end

Although clearly the distinction between a mixin and a ducktype is the
ducktypes global influence. Quite powerful! Yet, I do imagine that with
this is place someone would call for selector namepsaces to reign in
the abundant flocks Onefurther step would have to be taken, at the
very least. a means of constraining them to specific scopes. Perhaps
that's a simple as limiting them the module space they are defined in?

In any case very interesting. I really wonder just how far one can take
this shift in paradigm?

T.