I'll have the duck!

[7rans]

*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.

 

[dblack]

Hi --

*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

--
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
(e-mail address removed) => me

 

[Phil Tomson]

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

 

[7rans]

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.

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.

 

[ara.t.howard]

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.

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:

1) 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.

2) 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

 

[dblack]

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.

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:

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.)

1) 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.

2) 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 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

kind regards.

-a

--
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
(e-mail address removed) => me

 

[Dumaiu]

Hi --



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" 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?....)

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.

True -- but it may have to do with how one defines "possible" 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.

The atomicity of a Ruby call makes for a nice, visceral experience,
doesn't it? :-D 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.

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.

Oh, really? Thanks for setting me straight.

 

[Benjohn Barnes]

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 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).

*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.

 

[ara.t.howard]

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.

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

 

[Benjohn Barnes]

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).

 

[ara.t.howard]

*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

 

[Daniel DeLorme]

*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

 

[Hal Fulton]

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.

Thank you very much for that clarification, Phil.


Hal

 

[Daniel DeLorme]

I meant to say predicate classes. Sorry.

Interesting. "predicate class" certainly sounds more serious than "duck type".
But oh so less funny ;-)


Daniel

 

[Hal Fulton]

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

 

[James Britt]

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.

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 Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://yourelevatorpitch.com - Finding Business Focus

 

[Chad Perrin]

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.

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.

 

[Hal Fulton]

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.

You're right, of course.

I apologize to Trans and to the group.


Hal

 

[ara.t.howard]

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

 

[Dumaiu]

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: