Daniel DeLorme wrote:
dblack@wobblini.net 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:
dblack@wobblini.net 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
--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net => me
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 7/25/06, 7rans <transfire@gmail.com> 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.
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).
On 25 Jul 2006, at 22:14, I wrongly wrote:
it seemed a lot like prototype classes
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
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
On Wed, 26 Jul 2006, Benjohn Barnes 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.
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
Benjohn Barnes 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
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:
dblack@wobblini.net 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 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.
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 Thomas 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.
Phil Tomson 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.
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 <transfire@gmail.com> 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.
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
On Wed, 26 Jul 2006, Phil Tomson wrote:
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.
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
Phil Tomson wrote:
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
Benjohn Barnes wrote:
I meant to say predicate classes. Sorry.
Interesting. "predicate class" certainly sounds more serious than "duck type". But oh so less funny 
Daniel
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.
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 thatsame_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
On Wed, 26 Jul 2006, ara.t.howard@noaa.gov wrote:
On Wed, 26 Jul 2006, Phil Tomson wrote:
kind regards.
-a
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net => me
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
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 Wed, 26 Jul 2006 dblack@wobblini.net wrote:
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
Hal Fulton wrote:
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.
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
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://yourelevatorpitch.com - Finding Business Focus
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
On Wed, 26 Jul 2006 dblack@wobblini.net 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".
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
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 Wed, Jul 26, 2006 at 10:33:12AM +0900, James Britt wrote:
Hal Fulton wrote:
>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.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.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham
James Britt wrote:
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
Zen Typing: The sound of one duck quacking.
On 7/25/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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'