On Wed, 26 Jul 2006, 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). 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.
sortof. even if you ignore the compile-time vs run-time semantics
between
ruby and c-- you still get nailed with ‘method_missing’ which may well
respond
to any message sent:
harp:~ > cat a.rb
class BlackBox
instance_methods.each{|m| undef_method m}
def method_missing(m, *a, &b) 42 end
end
%w( fee fie fum id send ).each{|m| p(BlackBox.new.send(m))}
harp:~ > ruby a.rb
42
42
42
42
42
this is a crucial distinction between any generic programming
methodology or
interface paradigm - this is really sending a message to an object which
may do
just about anything with it.
regards.
-a
7rans wrote:
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.
As far as I am concerned, David is smarter in his sleep than
you are awake. In addition to being knowledgeable, he is polite
and civilized and can speak his native language. On top of that,
he has made uncountable contributions to this community. Your
greatest contribution was during the time you quit posting.
Hal
Hal F. wrote:
and civilized and can speak his native language. On top of that,
he has made uncountable contributions to this community. Your
greatest contribution was during the time you quit posting.
I like the work Trans has done, but I’m really surprised to read such
harsh words about David Black. Hal’s summation (sentences 2+3) is
dead-on, though the personal sniping (however much I think I understand
Hal’s reaction) doesn’t help.
I fear that there has been a gradual shift in the group demeanor. Where
once personal attacks were few and far between, and those who engaged in
them were quickly called on it, it seems now that (some) people are more
willing to toss around nasty, personal comments, and (many) more willing
to excuse others or turn a deaf ear.
“Matz is nice, so we are nice” was something of the group motto, but may
become just another archaic phrase.
–
James B.
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://yourelevatorpitch.com - Finding Business Focus
James B. wrote:
to excuse others or turn a deaf ear.
“Matz is nice, so we are nice” was something of the group motto, but may
become just another archaic phrase.
You’re right, of course.
I apologize to Trans and to the group.
Hal
On Wed, 26 Jul 2006 [email protected] wrote:
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 was thinking about this on my ride home and recalled a term used in
damian
conway’s object oriented perl book (a fastastic book on oo programming
btw.)
and a term he used way back then : ‘interface polymorphism.’ the more i
thought about it the more i like the term better than ‘duck typing’
because
it’s closer in spirit to the idea of something being an acceptable
object
merely by implimenting (via method_missing or whatever) a certain set of
behvaiours.
2 cts.
-a
7rans wrote:
…
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.
For the record, I’ll cross-reference with Mr. Black’s 2:16 PM post,
where he addressed this:
[email protected] wrote:
…
On Wed, Jul 26, 2006 at 10:33:12AM +0900, James B. wrote:
you are awake. In addition to being knowledgeable, he is polite
once personal attacks were few and far between, and those who engaged in
them were quickly called on it, it seems now that (some) people are more
willing to toss around nasty, personal comments, and (many) more willing
to excuse others or turn a deaf ear.
I’m not prepared to render judgment on Hal at the moment, but 7rans
should receive at least as much blame for rudeness as Hal (if not
moreso, in a “he started it” sort of sense), for that “still an ass”
crack.
Having been on this list only a few days so far this time around, I
can’t offer any useful observations on the general demeanor of the
community as embodied by ruby-talk.
On 7/25/06, [email protected] [email protected] wrote:
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’ 
Zen Typing: The sound of one duck quacking.
Gregory B. wrote:
…
Zen Typing: The sound of one duck quacking.
No, really, what *is* the sound of a duck typing?
7rans wrote:
…
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?
… # yadda-yadda
A valid semantic point–‘ElegantWay’ isn’t a one hundred per-cent fit
for a likeness; but it made me laugh, and it’s the sort of example I
was trying to think of but couldn’t. Still, I am becoming increasingly
convinced that Mr. Black is right and duck typing cannot effectively be
modularized. To recap: Duck typing is the near absence of type
checking in the Ruby core language. It’s a consequence of Ruby’s
completely dynamic nature and the lack of distinction between method
definition and method call. I think Dave T. called attention to
and named it because its appearance was almost accidental and it was
interesting enough to deserve a head-on approach, or at least
consideration of one. But conceptually it’s still an absence of
something (type validation)–a vacancy. A ‘TypeChecking’ module might
be useable, but one for duck typing would be a ‘NoTypeChecking’ module,
i.e., empty. You’d be trying to automate the act of leaving something
undone. Actually, it makes me think of the ‘Acme::Don’t’ module on
CPAN.
The elimination of any reliance on class hierarchies really would
leave you with a prototype-based model.
On Wed, 26 Jul 2006, Gregory B. wrote:
On 7/25/06, [email protected] [email protected] wrote:
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’
Zen Typing: The sound of one duck quacking.
touche!
-a
On Wed, Jul 26, 2006 at 01:48:39PM +0900, Gregory B. wrote:
On 7/25/06, [email protected] [email protected] wrote:
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’
Zen Typing: The sound of one duck quacking.
Shouldn’t that be “the sound of one wing flapping”?
Chad P. wrote:
Shouldn’t that be “the sound of one wing flapping”?
This discussion brings back memories of the duck and the bird arguing in
“Peter and the Wolf”. The bird asks the duck, “What kind of a bird are
you if you can’t fly?” Well … I’ve seen (mallard) ducks fly. They
really have to work hard to get airborne, though. This must have been a
fat domesticated duck.
“The secret word is Ruby”.
On Jul 26, 2006, at 8:13, Jake McArthur wrote:
let’s-make-everything-twice-as-confusing.
Surely AJAX already took that award?
Hi –
On Wed, 26 Jul 2006, [email protected] wrote:
thought about it the more i like the term better than ‘duck typing’ because
it’s closer in spirit to the idea of something being an acceptable object
merely by implimenting (via method_missing or whatever) a certain set of
behvaiours.
It sounds like a very useful term, but maybe not a synonym for duck
typing…? I’m not sure, but it doesn’t sound like one would say:
Interface polymorphism is a way of thinking about programming in Ruby
[if I’m paraphrasing Dave T. correctly]. One might say: Ruby
offers interface polymorphism, which encourages duck typing [if I’m
using i.p. correctly :-]
My view is that we don’t need to choose a winner-take-all term to
refer collectively to everything connected with Ruby’s type
mechanism, including the way(s) programmers use that mechanism. We
can have a slightly whimsical but expressive term like “duck typing”
to refer to one aspect of it, and other terms to refer to other,
related things. I’m fond of “duck typing”, “quasi-prototyped
objects”, and various other terms – all of which refer to something
of interest.
David
[email protected] wrote:
i was thinking about this on my ride home and recalled a term used in damian
conway’s object oriented perl book (a fastastic book on oo programming btw.)
and a term he used way back then : ‘interface polymorphism.’ the more i
thought about it the more i like the term better than ‘duck typing’ because
it’s closer in spirit to the idea of something being an acceptable object
merely by implimenting (via method_missing or whatever) a certain set of
behvaiours.
Holy cow; the whole thread was worth it just for this. This is on
target: in ruby-talk 03608 matz in fact mentions as an illustration of
‘implementation polymorphism’ the Enumerable module, because the use of
each() is the only requirement defined for compatibility. I will posit
as a distinction that ‘duck typing,’ as we call it, is a description of
an innate behavior of the language, while ‘implementation inheritance’
would be D. Conway’s name for the general consequence of building
projects with this kind of model in mind.
On Jul 25, 2006, at 10:43 PM, [email protected] wrote:
interface polymorphism
I have heard this term before too (or maybe I just thought of it
independently, not sure). I, too, prefer it to “duck typing” as it
more clearly demonstrates the core of the concept.
I nominate this as the new-name-for something-that-already-had-a-name-
and-didn’t-really-need-a-new-one-but-this-one-is-better-so-let’s-make-
everything-twice-as-confusing.
Hi –
On Wed, 26 Jul 2006, Dumaiu wrote:
Holy cow; the whole thread was worth it just for this. This is on
target: in ruby-talk 03608 matz in fact mentions as an illustration of
‘implementation polymorphism’ the Enumerable module, because the use of
each() is the only requirement defined for compatibility. I will posit
as a distinction that ‘duck typing,’ as we call it, is a description of
an innate behavior of the language, while ‘implementation inheritance’
(Do you mean ‘interface polymorphism’?)
would be D. Conway’s name for the general consequence of building
projects with this kind of model in mind.
Don’t forget, though, that duck typing was originally intended as a
description of something that a programmer does. I’ve also always
tended to see it as a property of the language (i.e., Ruby as a
“duck-typed” language, as Jim W. has said) – since the
method-call is always isolated from any ancestry checks and so forth
that surround it – but, as I understand Dave’s take on it, it does
refer at least equally to a programming attitude/style/philosophy (or
whatever the best term is).
David
M. Edward (Ed) Borasky wrote:
This discussion brings back memories of the duck and the bird arguing in
“Peter and the Wolf”. The bird asks the duck, “What kind of a bird are
you if you can’t fly?” Well … I’ve seen (mallard) ducks fly. They
really have to work hard to get airborne, though. This must have been a
fat domesticated duck.
I’ve heard that the turkey can fly. That suprised me; I would have
been sure that that one was too fat.
“The secret word is Ruby”.
Actually, there are no corroborated reports of Ruby-powered ducks
spontaneously taking to flight. I would like to delay work on the
‘LameWalk’ and ‘BlindSee’ gems until we have confirming evidence for
this.
On Wed, 26 Jul 2006 [email protected] wrote:
It sounds like a very useful term, but maybe not a synonym for duck
typing…? I’m not sure, but it doesn’t sound like one would say: Interface
polymorphism is a way of thinking about programming in Ruby [if I’m
paraphrasing Dave T. correctly]. One might say: Ruby offers interface
polymorphism, which encourages duck typing [if I’m using i.p. correctly :-]
right. one would say something like
‘make your methods accept interface polymorphic objects for maximum
re-use’
eg
def m obj
p obj.foobar # takes any obj that responds_to? ‘foobar’ - NEVER do
we check type
end
afaikt this is a concrete prescription for ‘duck typing’ that avoids
mentioning types!
My view is that we don’t need to choose a winner-take-all term to refer
collectively to everything connected with Ruby’s type mechanism, including
the way(s) programmers use that mechanism. We can have a slightly whimsical
but expressive term like “duck typing” to refer to one aspect of it, and
other terms to refer to other, related things. I’m fond of “duck typing”,
“quasi-prototyped objects”, and various other terms – all of which refer to
something of interest.
indeed - still that ‘type’ bit is quite a cause for confusion.
cheers.
-a