I'll have the duck!

Ruby
21

On 7/24/06, Alex Y. [email protected] wrote:

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.

–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

  • Albert Einstein
22

Mat S. wrote:

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/

23

Hi –

On Mon, 24 Jul 2006, Robert D. wrote:

Although I said intolerant I want to add immediately that they are

–

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

24

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

25

[email protected] 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?® }
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?

26

Hi –

On Tue, 25 Jul 2006, Daniel DeLorme wrote:

module DuckTyping
@@quacks = Hash.new{ |h,k| h[k] = {} }
[…]
Duck.new.quack_loudly #=> “QUACK!”
Dog.new.quack_loudly #=> NoMethodError

I guess you’d have to think of a new name to refer to what has in the
past been called “duck typing” :slight_smile:

David

27

Hi –

On Tue, 25 Jul 2006, [email protected] wrote:

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

If it’s a shift in paradigm, then it isn’t “duck typing” (which is a
term invented to describe aspects of programming in Ruby).

Please choose a different animal :slight_smile:

David

28

Daniel DeLorme wrote:

@@quacks = Hash.new{ |h,k| h[k] = {} }
[snip cool code]

end

nifty?

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

I wonder then, if we take up John C.'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 :wink: 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.

29

Hi –

On Tue, 25 Jul 2006, Chad P. wrote:

. . . not that anyone outside of NeXT used Objective-C for most of its
existence.

I’ve always thought that Dave T. coined it, and that it then
caught on (including outside of Ruby). Either way – I think that
using “duck” in method and class names dilutes the meaning of “duck
typing”, and also does a disservice to the stuff people are writing,
some of which may be quite interesting. When I see these
prototype-style libraries named “duck” this and that, I’m just aware
of the fact that duck typing isn’t something one can implement in
code, and that therefore the point of this code is being obscured
rather than revealed by the naming.

David

30

On Tue, Jul 25, 2006 at 06:01:45AM +0900, [email protected] wrote:

using “duck” in method and class names dilutes the meaning of “duck
typing”, and also does a disservice to the stuff people are writing,
some of which may be quite interesting. When I see these
prototype-style libraries named “duck” this and that, I’m just aware
of the fact that duck typing isn’t something one can implement in
code, and that therefore the point of this code is being obscured
rather than revealed by the naming.

You may well be right. I’m afraid I’m not an expert in the etymology of
the term “duck typing”. I’ll take your word for it, for the time being.

31

On Tue, Jul 25, 2006 at 05:48:29AM +0900, [email protected] wrote:

If it’s a shift in paradigm, then it isn’t “duck typing” (which is a
term invented to describe aspects of programming in Ruby).

Please choose a different animal :slight_smile:

The term “duck typing” predates Ruby, as I recall. I seem to remember
it being applied to Objective-C, for instance.

. . . not that anyone outside of NeXT used Objective-C for most of its
existence.

32

[email protected] wrote:

I’ve always thought that Dave T. coined it, and that it then
caught on (including outside of Ruby). Either way – I think that
using “duck” in method and class names dilutes the meaning of “duck
typing”, and also does a disservice to the stuff people are writing,
some of which may be quite interesting. When I see these
prototype-style libraries named “duck” this and that, I’m just aware
of the fact that duck typing isn’t something one can implement in
code, and that therefore the point of this code is being obscured
rather than revealed by the naming.

This argument has been made before, notably by you, and it simply does
not hold-up to scrutiny. First of all, how can a programming language
do anything that does not arise from implementation. That’s completely
contradictory. But I’ll take that to be a misstatement, and you
actually just mean that duck-typing is not something you explicitly
declare, but rather is an implicit occurance of not imposing type
restrictions on method arguments. However you are wrong to think that
there is no imposition being made at all. When an object is the
receiver of a message to which it does not respond, it readily object
with a resulting NoMethodError. So disavowing #respond_to? as
antithetical to duck-typing is simply delusional. Explicit is just the
otherside of the implicit coin. Defining a set of methods based on a
conformity to a “duck type” is therefore not contrary to the original
coinage, but in reality furthers it by taking into account all side.
Which is what I was saying with my original post, that the “duck”
concept as currently implemented may yet be only half turned. It would
then be clear that your hold to this specific idea of the
inexpressibility of a duck type is effective only at stymieing
innovation in the area.

T.

33

I think that AOP is a much more specific approach tailored for
particular types of problems in particular types of OO applications
where the the classes can’t be separated nicely. AspectR looks to me
(on the surface) to have more in common with Erik V.'s
wrap_method() routine, linked to earlier in the thread.

34

I’m not sure what the best place for this is; sorry. The following are
my views:
What we know as ‘duck typing’ is not really a programming paradigm,
but a set practices as Mr. Black says–merely the “yin” end of the
type-checking continuum. I first learned about it, although of course
not by that name, from studying C++ templates, where also the
prevailing wisdom is that you shouldn’t assume anything more about your
library’s client’s code than is absolutely necessary. The ‘duck
typing’ moniker that marks it as a novelty is most useful against the
background of static languages, where type-checking helps prevent
runtime errors. For Ruby, where every error is runtime, duck typing
is the raw form of its behavior, and should be recognized as quickly as
possible, because it isn’t always good. At its utmost, duck typing is
the total absence of validation. You are saying that nothing about
your client’s program is worth trying to predict, that ‘if it works, it
works,’ and if it doesn’t, he’ll know because it just blew up.
Hmm. I see where type-checking came from. As far as Ruby best
practices go, I think ‘duck typing’ just means using respond_to?() more
than kind_of?() and include?(). If you really wanted to, dumping class
use entirely and turning Ruby into a prototype-based language wouldn’t
be too hard: you’d use Object::new() only, define only singleton
methods, and extend objects with clone(); and if you wanted to
delegate, you’d keep an array of references of “parent” objects,
Perl-style.
Personally, I feel that Ruby needs more, rather than less, type
safety, to balance its natural inclination otherwise and because no
amount of ‘duck typing’ disaffirms that erroneous behavior is best
caught as soon as possible. But I don’t think anyone would advocate a
return to rigid inheritance checking, which realization the deprecation
of type() notably indicates.

35

Hi –

On Tue, 25 Jul 2006, 7rans wrote:

code, and that therefore the point of this code is being obscured
rather than revealed by the naming.

This argument has been made before, notably by you, and it simply does
not hold-up to scrutiny. First of all, how can a programming language
do anything that does not arise from implementation. That’s completely
contradictory. But I’ll take that to be a misstatement, and you
actually just mean that duck-typing is not something you explicitly
declare, but rather is an implicit occurance of not imposing type
restrictions on method arguments.

No misstatement: Duck typing isn’t something one can implement in
code. If you say, “So-and-so codes in an elegant way”, that doesn’t
mean that the next step is to create an ElegantWay module. Duck
typing, as Dave T. has put it, is a way of thinking about
programming in Ruby. You may write a module that people who think
that way find useful, but that doesn’t mean that it should be called
DuckTyping. You cannot implement a way of thinking, per se, in code.

then be clear that your hold to this specific idea of the
inexpressibility of a duck type is effective only at stymieing
innovation in the area.

I seem to have hit some kind of nerve here. (To parapharse your
earlier comment: I’ll take your characterization of me as “delusional”
as a misstatement :slight_smile: But reread what I wrote originally. It’s got
nothing to do with stymying innovation. I’m just suggesting that
hitching all of this experimentation to the “duck/quack” wagon, when
it comes to method and class and module names, does a disservice to
both the duck typing concept (which isn’t about writing modules called
Duck) and to the code you’re writing (the possible usefulness of which
is obscured by the peculiar names).

David

36

Daniel DeLorme wrote:

module DuckTyping
o.instance_method(methodname.to_sym)
return nil
Object.module_eval{ include DuckTyping }
def quack
Duck.new.quack_loudly #=> “QUACK!”
Dog.new.quack_loudly #=> NoMethodError

nifty?

Isn’t this stuff used i Aspect Oriented Programming as well? I only know
what I’ve read in the RCR, so I’m not sure.

Cheers,
Daniel

37

Hi –

On Tue, 25 Jul 2006, Dumaiu wrote:

runtime errors. For Ruby, where every error is runtime, duck typing
is the raw form of its behavior, and should be recognized as quickly as
possible, because it isn’t always good. At its utmost, duck typing is
the total absence of validation. You are saying that nothing about
your client’s program is worth trying to predict, that ‘if it works, it
works,’ and if it doesn’t, he’ll know because it just blew up.

True, though that’s partly why test-driven development is so big among
Rubyists.

Hmm. I see where type-checking came from. As far as Ruby best
practices go, I think ‘duck typing’ just means using respond_to?() more
than kind_of?() and include?().

At some point in the past I think I posited a distinction between
“soft duck typing” and “hard duck typing” :slight_smile: Very much along the
lines you’re describing: soft duck typing involves the “extra” layer
of respond_to? and hard duck typing doesn’t. respond_to? is certainly
a sensible precaution to take, in many cases, and one that operates in
the orbit of the object itself (as opposed to kind_of?).

(I’m not quite sure what you mean about include?..)

If you really wanted to, dumping class
use entirely and turning Ruby into a prototype-based language wouldn’t
be too hard: you’d use Object::new() only, define only singleton
methods, and extend objects with clone(); and if you wanted to
delegate, you’d keep an array of references of “parent” objects,
Perl-style.

It seems to me (though I don’t know any of the prototyped languages in
any depth) that Ruby indeed gives you both: a per-object universe, and
a class system. Ultimately, the former sort of “wins”, in the sense
that classes are objects and so on… but actually I think the two are
in a nice balance.

Personally, I feel that Ruby needs more, rather than less, type
safety, to balance its natural inclination otherwise and because no
amount of ‘duck typing’ disaffirms that erroneous behavior is best
caught as soon as possible.

True – but it may have to do with how one defines “possible” :slight_smile: One
could say that no amount of early checking can change the fact that
the only absolute way to know what sending a message to an object will
do is to send the message to the object. In practice, one settles for
non-absolute ways, not only because they tend to work but because
they’re all that’s available. But I’m always fascinated by the
singularity of a Ruby method call: there’s nothing else around it that
really, absolutely pertains to it.

But I don’t think anyone would advocate a
return to rigid inheritance checking, which realization the deprecation
of type() notably indicates.

Actually the deprecation of type, I believe, has a different cause.
As I understand it, in early Rubies there were problems parsing:
obj.class, so a name other than “class” had to be used for that
method. Now that obj.class can be parsed, “type” is no longer needed
– and, as Matz has said, it’s problematic because it discourages duck
typing.

David

38

[email protected] wrote:

I’ve always thought that Dave T. coined it, and that it then
caught on (including outside of Ruby). Either way – I think that
using “duck” in method and class names dilutes the meaning of “duck
typing”, and also does a disservice to the stuff people are writing,
some of which may be quite interesting. When I see these
prototype-style libraries named “duck” this and that, I’m just aware

So your objection is merely semantic? If DuckTyping isn’t the “proper”
word to use, what would you suggest? That little module I knocked
together was just a way to mix-in methods into any object that responds
to the proper quacks–er, messages. DuckTyping seems like a good way to
describe that to me.

of the fact that duck typing isn’t something one can implement in
code, and that therefore the point of this code is being obscured
rather than revealed by the naming.

That sounds very silly, like saying that OOP or functional programming
can’t be implemented in code.

Daniel

39

Ron J. [email protected] writes:

On Mon, 24 Jul 2006 08:09:58 +0900, [email protected] wrote:

Now anything that responded to #to_a could use #transform. I’m not sure
how far this can be taken. Can classes be undone altogegther? But in
anycase, it seems very cool, and I wonder what kind of overall effect
it could have on coding?

there’s a language called “self” that has no classes, only prototypes. if you
can find some material on that, i think you’ll find it interesting.

While you’re at it, have a look at Slate, that also removes
single-dispatch.

40

On Tue, 2006-07-25 at 02:49 +0900, [email protected] wrote:

From the code above, this appears to be going in the direction of formal
‘interface’ concept. If ‘each’ is a “ducktype”, and ‘each’ has a set of
well defined methods, except for the fact that code exists in those
methods, this is tantamount to publishing an interface.

From the little that I understand, the whole concept of duck typing is
about not being concerned with a full published interface (or, a full
published inheritance) of the receiver; rather, we are only concerned
with whether the receiver answers the current message.

I could be wrong in understanding your code example, though!

Greetings,
JS