Hmmm… David, my point is simply this: I understand your concern with
regards to the intended coinage of “duck typing” by Dave T… But
this discussion is too protozoic to be overly concernd with exacting
nomenlature at this point. It is enough to convey the idea intended.
T.
[email protected] wrote:
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.
Well, besides the fact that all code is the implementation of a way of
thinking, have you considered that you may be restricting the concept
arbitrarily? You say DuckTyping is like ElegantWay, and yet I was able
to use DuckType in psuedo-code in a meaningful way. I’d like to see you
do the same with ElegantWay. If what you say is true, how is that
possible?
Of course, you may argue that it’s not meaningful, and that actually I
just have a delusional concept of duck typing that allows me to think
it’s meaningful. Yet somehow everyone else in this discussion was able
to undestand me. Or are we all just delusional? Well, however you want
to slice up the semantic salad, the bottom line is I’m trying to talk
to people, and I’m going to use words that convey my meaning as
concisely as possible. “Duck” works fantasically well here --trying to
explain in another way, or coining another term would only make it more
difficult. Moreover, if I had, I imagine someone would have eventually
say, “isn’t this just duck typing”. After all, it’s already been
erroneously called prototype-based OOP and AOP.
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 misstatementBut 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).
Bull hockey (does this do a disservice to bulls or hockey? 
The problem, David, is that you are adding nothing constructive to
the conversation. You are merely being persnickety over terminology. No
one else is having any trouble over the use the word “duck” in the
code, or what it represents. Certainly I don’t expect “duck” to become
a keyword of the language, but it serves perfectly well for this
exploration – it is ultimately an analogy after all, “if it walks like
duck and talks like a duck…” We’re using the analogy.
T.
Perhaps you should try being ‘delusional,’ for a change; doesn’t your
customary lucidity become oppressive sometimes? Take a break. For
example, the next time someone levies that accusation, you say, ‘Thank
you, madam; two lumps.’
-JDaniel DeLorme wrote:
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.
It's confusing. For my part, I wouldn't mind so much seeing a module
called ‘DuckTyping’–I would think, ‘Okay, here’s someone taking a shot
at codifying a general concept’; but encountering the words ‘duck’ and
‘quack’ in actual method names makes me suspicious that someone is
trying to be “cute.” Or the issue can be linguistic. To take the
example of your test module, on line 2 I see
@@quacks = +whatever+
and my mind hits a rut. Is this a list of objects|methods|classes that
are capable of quacking, or of the different vocal sounds that ducks
make? Similarly, farther down you have a method called
ducktype_method(methodname)
But is ‘ducktype_method’ a noun or a verb? Perhaps you can apperceive
the meaning of a method definition at first glance, but I (and probably
some others) have to think about it, and the reuse of the same minimal
vocabulary
ducktype :quack do
def quack_loudly
quack.upcase
end
end
is frustrating. It would be even more so if I were brand-new to Ruby.
That sounds very silly, like saying that OOP or functional programming
can’t be implemented in code.
For this comparison to be valid, you would have to turn duck typing
into a programming paradigm: Duck-Oriented Programming. Is that really
worth it?
Hi –
On Tue, 25 Jul 2006, Daniel DeLorme wrote:
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.
The problem is that “duck typing” is already “taken”
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.
I do wish we could keep “silly” and “delusional” and so on out of it.
Anyway – my point is that duck typing is not a library-level language
facility that you or I can write and ‘require’ and thus add to Ruby.
Even if there’s a module called DuckTyping, people who ignore that
module are still 100% as capable of using a duck-typing approach as
people who use the module. The existence of the module is orthogonal
to both the duck-typing friendliness of the language, and the
duck-typing programming style of the people using the language.
It’s a bit like writing a module called ObjectOrientation. The module
might do something wonderful, but it doesn’t add object orientation to
Ruby (I think I stole that example from Chad F., from a
discussion of something else a couple of years ago.)
So my suggestion was, and is, to name your module something else, and
then trust duck-typing devotees (and others) to examine it and decide
whether it helps them out.
David
[email protected] wrote:
The problem is that “duck typing” is already “taken”
sigh
And So, Faced With Insurmountable Semantic Opposition And A
Total Lack Of Suggestions, I Was Faced With The Lonely Task
Of Renaming My Proof-Of-Concept Module, Carefully Removing
Any Offending Reference To The Word “Duck”:
module DependentMethods
@@dependent_methods = Hash.new{ |h,k| h[k] = {} }
def depending_on(*requisites, &block)
o = self.is_a?(Class) ? self : self.class
requisites.unshift(o)
before = o.instance_methods
o.class_eval(&block)
after = o.instance_methods
for methodname in (after - before)
methodname = methodname.to_sym
@@dependent_methods[methodname][requisites] =
o.instance_method(methodname)
o.send(:remove_method, methodname)
end
end
def dependent_method(methodname)
@@dependent_methods[methodname.to_sym].each do |requisites, m|
if self.kind_of?(requisites[0])
if requisites[1…-1].all?{ |r| self.respond_to?® }
return m
end
end
end
return nil
end
def method_missing(methodname, *args, &block)
if m = dependent_method(methodname)
m.bind(self).call(*args, &block)
else
super
end
end
end
Object.module_eval{ include DependentMethods }
depending_on :quack do
def quack_loudly
([quack.upcase]*(1+rand(3))).join
end
end
class Anatidae
def quack
“quack!”
end
end
d = Anatidae.new
puts d.quack_loudly #=> “QUACK!”
[email protected] wrote:
Hi –
On Tue, 25 Jul 2006, Daniel DeLorme wrote:
[email protected] wrote:
Anyway – my point is that duck typing is not a library-level language
discussion of something else a couple of years ago.)So my suggestion was, and is, to name your module something else, and
then trust duck-typing devotees (and others) to examine it and decide
whether it helps them out.
Er… Did someone put you in charge of the duck type club? I am a
duck-typing “devotee”. But I am not a dogmatic lexicon beater. My use
of the term “duck” and “type” has a very clear sematic value to the
conversaion percisely because of the term Dave has “taken” --taken to
have a useful meaning. But you want to insist that my use of the term
isn’t “proper” and continue to waste our time on matters of “rosey”
triviality. Then let me oblige you in your own pursuit…
The term ducking typing, according to your own convictions can be
nothing of the sort. For it is completely contradictory to call
something a “type” when by defintion it excludes anything type
whatsoever. It would be more appropritate call it duck anti-typing, if
anything. Furthermore a duck is featuerd animal that tends to float
around in ponds all day and fly south for the wnter. I fail to see any
such creatures in your concept.
You see, the words “duck” and “type” were “taken” before you or Dave
hit the scene So I advise you to find another term.
T.
Daniel DeLorme wrote:
[email protected] wrote:
The problem is that “duck typing” is already “taken”
sigh
And So, Faced With Insurmountable Semantic Opposition And A
Total Lack Of Suggestions, I Was Faced With The Lonely Task
Of Renaming My Proof-Of-Concept Module, Carefully Removing
Any Offending Reference To The Word “Duck”:
module DependentMethods
Yep. Now I’m wondering what they hell your’re talking about ;-D
Maybe SignitureType, SignType, or just Sign would be work.
T.
Hi –
On Tue, 25 Jul 2006, Daniel DeLorme wrote:
[email protected] wrote:
The problem is that “duck typing” is already “taken”
sigh
And So, Faced With Insurmountable Semantic Opposition And A
Total Lack Of Suggestions, I Was Faced With The Lonely Task
Of Renaming My Proof-Of-Concept Module, Carefully Removing
Any Offending Reference To The Word “Duck”:
I have no idea how or when or why this all got so acrimonious. For
what it’s worth, names like dependent_method (as in your second
iteration) are much more expressive and communicative than duck and
quack and so on. But you should use whatever names you like. I’m
only pointing out potential pitfalls.
David
Phil T. wrote:
Actually, David is doing something very important: he’s making sure
important. If you take a name (duck typing) and apply it to a concept
that’s different than what is the accepted association in the
community, then in some way your ‘theft’ diminishes our ability to
communicate within our discourse community. Some would even say it
diminishes the whole concept of ‘duck typing’. Look up Wittgenstein
on wikipedia.
But that’s not what I am doing. Reread what I have wrote. I am not
“stealing” anything. I am using teh current terminology as a jumping
off point preceisly becuase that current terminology Is the jumping off
point by which I arrived at the notion to begin with. It’s useful for
the discussion and exploration. No one’s suggestion that “ducktype”
shuold added to the langaugge nor even that it would be the some fterm
used in some addon library. In fact I would not support any such thing
b/c duck type is really a prerty poor term to begin with (as I joking
poitn out to David).
Anyhow, as far as I’m concerned David has once again runied a
conversation that was actually showing signs of baring fruit. As this
point you can call it “donkey type” for all I care. Because a donkey by
any other name is still as ass.
T.
On 7/25/06, 7rans [email protected] wrote:
The problem, David, is that you are adding nothing constructive to
the conversation. You are merely being persnickety over terminology. No
one else is having any trouble over the use the word “duck” in the
code, or what it represents. Certainly I don’t expect “duck” to become
a keyword of the language, but it serves perfectly well for this
exploration – it is ultimately an analogy after all, “if it walks like
duck and talks like a duck…” We’re using the analogy.
Actually, David is doing something very important: he’s making sure
that we name things correctly and that we not change our terminology.
You’ve used the term ‘duck-typing’ in a way that differs from it’s
traditional use in tthe Ruby community. David is calling you on that
and basically saying that either you need to come up with a different
terminology to describe what you’re doing or we’ll have to come up
with a different name for what currently has been considered
‘duck-typing’.
It’s been said that naming is one of the most important acts of
programming. What we call things, objects and even concepts is
important. If you take a name (duck typing) and apply it to a concept
that’s different than what is the accepted association in the
community, then in some way your ‘theft’ diminishes our ability to
communicate within our discourse community. Some would even say it
diminishes the whole concept of ‘duck typing’. Look up Wittgenstein
on wikipedia.
Phil
On Wed, 26 Jul 2006, [email protected] wrote:
hi phil-
on the one hand, i agree with you. on the other hand though, it’s important
to realize that no language/terminology is static. one of my pet peeves are
people who cling too tightly to rules or accepted meanings since, if we were
all like that, no new words or meanings would every spring into existence.
Let’s not get too global about this. Disagreeing about a Ruby module
name does not mean thinking that language, in general, is static, etc.
etc. I can prove my post-structuralist credentials to you any time
you feel you need evidence that I’m aware of the rudiments of
post-Saussurian lingustics Meanwhile, let’s get back to the topic
at hand.
publicly and tom releases tons of code), i’m willing to at least consider
that
our notion of duck typing may be able to be improved upon. in partucular, i
feel that inclusion of the word ‘typing’ in ‘duck typing’ is totally broken
with respect to the way the purists, like david, are using it: their
argument
basically goes that you cannot code ‘duck typing’ because one cannot know
apriori, using any current methodology available in ruby, whether or not a
method call or set of method calls with work out how you require them to.
this is flawed in at least two ways:
That’s not exactly what I’ve been saying; rather, my point has been
that I think that the concept of “duck typing” is in a category that
isn’t a category of things that can be written in code. If it is
something that can be written in code, then we need a new term for the
thing we used to call “duck typing”, which is a programming practice
that does not depend on or have any special relationship to any
particular modules or methods. (But let’s drop it; I’ve obviously
failed to put across that point.)
you concede that some sort of apriori checking can be used to determine
same_duck_type = [a,b].each{|obj| obj.send ‘msg’ rescue break false}
not toms since present reasoning about ‘duck typing’ does indeed imply an
infinite number of one member sets and it, therefore, not very useful.
I think one of the interesting things about Ruby is that it’s “ducks
all the way down”. respond_to? is just a method, etc. (This should
appeal to your Derridian side As with language in general, one
just goes ahead and uses it, based on pragmatic considerations and
experience. Language itself is, as you’ve pointed out, unfixed – but
that doesn’t mean that we just stare helplessly at each other, nor
that you look at your own first paragraph and despair of what the
words mean. Similarly, the mise-en-abyme of Ruby messages doesn’t
mean that one can’t do anything.
i understand the notion of just writing code and ‘seeing if objects can act
in that role’ as being a philisophical contruct - nevertheless i also think
that it’s certainly understood and implied in the term ‘type’ that certain
keys fit in certain locks and that unless a test can be made to atomicaly
test for this condition the phrase ‘type’ is in error.
I’ve always felt that the Achilles’ heel of the duck typing metaphor
was the “then it is a duck” – which implies that there’s a Duck
thing out there which something else can “be”. I don’t think it’s
supposed to be an airtight analytical tool for Ruby’s design, though,
just (as Dave says) a way of thinking about programming in Ruby.
David
[email protected] wrote:
prevailing wisdom is that you shouldn’t assume anything more about your
True, though that’s partly why test-driven development is so big among
Rubyists.
Whew! That’s a relief.
At some point in the past I think I posited a distinction between
“soft duck typing” and “hard duck typing”
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?..)
I meant Module#include?(), as the mixin-checking counterpart to
inheritance-checking.
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.
I agree. Classes and modules complement each other well, and an
immutable object prototype kept around only for cloning really isn’t
very different from a class definition. I like the support for
multiple approaches.
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.
The atomicity of a Ruby call makes for a nice, visceral experience,
doesn’t it? 
I’m glad you pinpointed the definition of ‘possible,’
because therein, as they say, lies the rub, and as it turns out I have
feelings about that, too. I’d advocate the use of respond_to?(),
because, as you say, it seems a ‘sensible precaution.’ I would
relegate method_missing() to the court of last resort and absolve
library designers from worrying about it. Because it’s so powerful,
its use can’t be predicted or guaranteed to operate properly; and if,
as I believe, every Best Practice should have a back door available for
exigency, method_missing() can never be a Best Practice, because it is
the ultimate back door.
I think you understood my point, though. Too much duck typing and you
have to throw up your hands in surrender.
Oh, really? Thanks for setting me straight.
On Wed, 26 Jul 2006, Phil T. wrote:
name (duck typing) and apply it to a concept that’s different than what is
the accepted association in the community, then in some way your ‘theft’
diminishes our ability to communicate within our discourse community. Some
would even say it diminishes the whole concept of ‘duck typing’. Look up
Wittgenstein on wikipedia.
hi phil-
on the one hand, i agree with you. on the other hand though, it’s
important
to realize that no language/terminology is static. one of my pet peeves
are
people who cling too tightly to rules or accepted meanings since, if we
were
all like that, no new words or meanings would every spring into
existence.
remember that someone - a single person - must alway utter a word or
imply a
meaning for the very first time. considering that the concept of ‘duck
typing’ is quite new and very, very far from having an exact meaning
(except
perhaps to a small group of rubyists), and considering that authorship
of code
bestows a certain latitude with respect to naming things (it’s my
opinion that
writing code is by far the most important activity of any rubyist and
doing so
give certain rights and privledges over those that do not release code
publicly and tom releases tons of code), i’m willing to at least
consider that
our notion of duck typing may be able to be improved upon. in
partucular, i
feel that inclusion of the word ‘typing’ in ‘duck typing’ is totally
broken
with respect to the way the purists, like david, are using it: their
argument
basically goes that you cannot code ‘duck typing’ because one cannot
know
apriori, using any current methodology available in ruby, whether or not
a
method call or set of method calls with work out how you require them
to.
this is flawed in at least two ways:
the same can be said for any language - you cannot know, in c for
example, if a method call on a pointer will core dump or not with
absolute
certainty. this is largely moot since, in the real world, we can do
all
sorts of things to know, with a finite certainty, that a certain
method call
will success. ‘respond_to?’ comes to mind.
the term ‘duck typing’ as it’s currently used, with no dis-respect
to
dave thomas, is flawed because the current usage does not, in fact,
suggest
any sort of ‘type’ or ‘equivalence class’! what i mean by that is,
unless
you concede that some sort of apriori checking can be used to
determine
‘duckness’ you cannot also use the work ‘typing’. why? because the
current
thinking is circular: people will say that this is not ‘duck typing’
obj.message if obj.respond_to? 'message'
because, only sending ‘message’ to ‘obj’ can really make that
determination.
well, if that is true, then it’s also true that we can never say that
same_duck_type = [a,b].each{|obj| obj.send 'msg' rescue break
false}
since that contains a race condition: we could conceivably send ‘a’ a
‘msg’,
then send ‘b’ a ‘msg’, only to come back to ‘a’ and find it no longer
responds to ‘msg’. what i’m saying is that if one accepts that the
only way
to employ/think-of/use ‘duck typing’ then one also accepts that it is
NOT a
‘typing’ system since each and every object belongs to it’s own
equivalence
class and that’s the same as no typing system. now, that may well be
the
case, but if it is then it’s the current terminology that needs fixed
and
not toms since present reasoning about ‘duck typing’ does indeed
imply an
infinite number of one member sets and it, therefore, not very
useful.
i understand the notion of just writing code and ‘seeing if objects
can act
in that role’ as being a philisophical contruct - nevertheless i also
think
that it’s certainly understood and implied in the term ‘type’ that
certain
keys fit in certain locks and that unless a test can be made to
atomicaly
test for this condition the phrase ‘type’ is in error.
kind regards.
-a
On 25 Jul 2006, at 05:06, [email protected] wrote:
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
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).
nods I tend to agree. When I posted earlier, it certainly seemed
like the person I replied to had “gone beyond” or “gone elsewhere”
from what I understand by the term “duck typing”. As I said, it
seemed a lot like prototype classes (adding capabilities to something
based on the fact that it already has certain capabilities). I’d also
agree that duck typing is a practice; you can do it with c++
templates, for instance, as far as I can see.
On Wed, 26 Jul 2006 [email protected] wrote:
Let’s not get too global about this. Disagreeing about a Ruby module name
does not mean thinking that language, in general, is static, etc. etc. I
can prove my post-structuralist credentials to you any time you feel you
need evidence that I’m aware of the rudiments of post-Saussurian lingustics
whew - because i can’t even spell that!
That’s not exactly what I’ve been saying; rather, my point has been that I
think that the concept of “duck typing” is in a category that isn’t a
category of things that can be written in code. If it is something that
can be written in code, then we need a new term for the thing we used to
call “duck typing”, which is a programming practice that does not depend on
or have any special relationship to any particular modules or methods. (But
let’s drop it; I’ve obviously failed to put across that point.)
i actually understand what you are saying. still, a programming concept
that
cannot be programmed is getting a bit metaphysical isn’t it? maybe ‘zen
typing’
I’ve always felt that the Achilles’ heel of the duck typing metaphor was the
“then it is a duck” – which implies that there’s a Duck thing out there
which something else can “be”.
exactly. it’s the ‘type’ in ‘duck typing’ that names the thing trying
to be
avoided. it is a paradox.
I don’t think it’s supposed to be an airtight analytical tool for Ruby’s
design, though, just (as Dave says) a way of thinking about programming in
Ruby.
agreed. i’ll just add that i think it can be improved upon and/or
refined.
cheers.
-a
On 25 Jul 2006, at 22:14, I wrongly wrote:
it seemed a lot like prototype classes
I meant to say predicate classes. Sorry.
See:
http://citeseer.ist.psu.edu/chambers93predicate.html
Abstract: Predicate classes are a new linguistic construct designed
to complement normal classes in objectoriented languages. Like a
normal class, a predicate class has a set of superclasses, methods,
and instance variables. However, unlike a normal class, an object is
automatically an instance of a predicate class whenever it satisfies
a predicate expression associated with the predicate class. The
predicate expression can test the value or state of the object, thus
supporting a form of implicit…
(Google’s top hit).
Benjohn B. wrote:
nods I tend to agree. When I posted earlier, it certainly seemed like
the person I replied to had “gone beyond” or “gone elsewhere” from what
I understand by the term “duck typing”. As I said, it seemed a lot like
prototype classes (adding capabilities to something based on the fact
that it already has certain capabilities).
Hmm, as far as I know “prototype classes” is about being able to call
.new on
any object. I’d like to know where you got that notion of “adding
capabilities”,
because that’s the first time I hear that about prototypes.
Daniel
Phil T. wrote:
It’s been said that naming is one of the most important acts of
programming. What we call things, objects and even concepts is
important. If you take a name (duck typing) and apply it to a concept
that’s different than what is the accepted association in the
community, then in some way your ‘theft’ diminishes our ability to
communicate within our discourse community. Some would even say it
diminishes the whole concept of ‘duck typing’. Look up Wittgenstein
on wikipedia.
Thank you very much for that clarification, Phil.
Hal
Benjohn B. wrote:
I meant to say predicate classes. Sorry.
Interesting. “predicate class” certainly sounds more serious than “duck
type”.
But oh so less funny
Daniel
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs