It’s not a coding style or technique; it’s an attribute of the
language.I disagree, with some proof by counterexample.
…
Therefore: Based on statements 1-5, “duck typing” is not specific
to ruby…
That was never asserted.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Hi –
- In any of the given languages, and Ruby, one can choose to check
types or not check types.
Or at least (in Ruby) you can check classes. But the point is that,
with all the calls to is_a? in the world, and whatever their result,
in the final anaysis an object either knows how to do what you ask it
to, or it doesn’t. You can’t change that underlying condition of
programming in Ruby, and that’s the condition people are referring to
when they describe “duck typing” as a condition of the language.
(Nor does that condition, that dynamism, go away if you decide to use
the term “duck typing” in a different sense.)
David
On Sun, 14 Sep 2003, Ryan Pavlik wrote:
–
David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
No, it’s related to the question “what is an object’s type?” as distinct
from “what is the class used to instantiate the object?”. The phrase
“duck typing” is no more and no less than a shorthand for “an object’s
type is determined entirely by the set of messages it responds to”, by
analogy with “static typing” (an object’s type is determined by a
compile-time declaration) and arguably as nothing more than a more
precise way of saying “dynamic typing”.
Any yes, it’s by no means specific to Ruby, but it is the way the
language defines a ‘type’.
martin
Ryan Pavlik rpav@mephle.com wrote:
Therefore: Based on statements 1-5, “duck typing” is not specific to
ruby, but rather made possible by the dynamic nature of a language.
Based on statements 6-7, duck typing is neither specifically provided
for nor compulsory, so it is not an attribute of the language.Thus, because it can be practiced, or not practiced; in ruby, or in
other languages; it must be a style available in dynamic languages,
rather than a specific feature of a particular language.
Yes, but it was asserted that it was a language attribute of ruby,
when you can practice it in other languages, which have no specific
provisions, any mention of “duck typing”, or common practice thereof.
(Although, in JavaScript, and most prototype-based languages, you
usually practice ‘duck-typing’ because that’s the way things are.
Pure prototype-OOP has no class, just an object that acts in a
particular manner—in this case, you could probably consider it a
feature of the language.)
On Sun, 14 Sep 2003 04:32:49 +0900 Michael Campbell michael_s_campbell@yahoo.com wrote:
Therefore: Based on statements 1-5, “duck typing” is not specific
to ruby…That was never asserted.
–
Ryan Pavlik rpav@mephle.com
“Damn ye and ye black ops mind games!” - 8BT
My 2 cents:
Duck typing is an answer to the questions, where are the type
declarations? What happens when I declare a variable without declaring
its type? How can I define, or call, a method without having to
explicitly specify the types the method accepts? Why is this so alien
to me with my background in (insert other language here)? etc., etc.
These are all good questions. The duck typing answer is saying – stop
thinking in terms of types in advance (of run time). Just send a
message to an object to perform a method. If you want to think about
type, try thinking about class instead.
Class – attributes, possible representations and methods (operations)
of values that can be created.
Duck typing isn’t the only answer and it’s not complete and it’s not a
formal paradigm. But it does inspire a lot of thought.
But if type matters for what you’re doing, by all means, think about it
– in fact, you must think about it. It’s just that there are huge
areas of development where, in a dynamic typing environment, explicit
concern with type is not necessary.
Regards,
Mark
No, it’s how you the programmer define a ‘type’. You have a few
options here; “duck typing” is just one of them. It has nothing to do
with what the languages specifies in this case.
On Sun, 14 Sep 2003 15:22:37 +0900 Martin DeMello martindemello@yahoo.com wrote:
–
Ryan Pavlik rpav@mephle.com
“That’s just horrible fanged death from the briny
depths of the sea attempting to kill us. Pay it no
mind.” - 8BT
Yes. You can do a lot of things with ruby that you can with other
languages; that it might have some ruby-cultural specific name isn’t
a new phenomenon, is it?
— Ryan Pavlik rpav@mephle.com wrote:
On Sun, 14 Sep 2003 04:32:49 +0900 > Michael Campbell michael_s_campbell@yahoo.com wrote:
Therefore: Based on statements 1-5, “duck typing” is not
specific to ruby…That was never asserted.
Yes, but it was asserted that it was a language attribute of
ruby,
when you can practice it in other languages, which have no specific
provisions, any mention of “duck typing”, or common practice
thereof.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Ryan Pavlik wrote:
Yes, but it was asserted that it was a language attribute of ruby,
when you can practice it in other languages, which have no specific
provisions, any mention of “duck typing”, or common practice thereof.(Although, in JavaScript, and most prototype-based languages, you
usually practice ‘duck-typing’ because that’s the way things are.
Pure prototype-OOP has no class, just an object that acts in a
particular manner—in this case, you could probably consider it a
feature of the language.)
Duck typing may not be a “feature” of Ruby, but it’s definitely supported by
Ruby. It’s also very well supported by Python, Perl, JavaScript, and
I’m sure
many other languages. The difference with Ruby is that Dave Thomas hangs
out here more and he’s the one who said it originally. 
Ruby does have some provisions that make it more supportive of duck typing,
though. For example, as I understand it, in Smalltalk (which I’m still
learning),
you define all your methods when you’re building the program, and then all
that is fixed. You can’t, for example, make an object of class Object
and then
write custom methods for that one object. So objects and types are more
dynamic in Ruby than in, say, Smalltalk, for example.
This, of course isn’t exclusive to Ruby. As I recall, JavaScript allows you
to add methods to arbitrary classes or objects. But, as I said, Dave Thomas
hangs out here, which is why Ruby people talk about duck typing and
JavaScript people don’t.
Cheers.
The only type checking the language does by default is to (dynamically)
see if a given object responds to a given message. Checking explicitly
for responds_to?, is_a? etc. merely add additional restrictions atop
the type system. By analogy, you could hack the built-in classes so that
all numbers were strictly integral, but you couldn’t say that the
language was agnostic towards supporting reals.
martin
Ryan Pavlik rpav@mephle.com wrote:
On Sun, 14 Sep 2003 15:22:37 +0900 > Martin DeMello martindemello@yahoo.com wrote:
> Any yes, it's by no means specific to Ruby, but it is the way the > language defines a 'type'.No, it’s how you the programmer define a ‘type’. You have a few
options here; “duck typing” is just one of them. It has nothing to do
with what the languages specifies in this case.
On Sun, 14 Sep 2003, Ryan Pavlik wrote:
It is impossible to use Ruby without using duck typing. As you
semi-paraphrase/semi-assert in a previous message:
" By the definitions given in this thread, duck typing is taking a
given object and pretending it’s the type you want, and letting
the language give you an error if it doesn’t work like you
expected."
Given Ruby’s dynamic nature, even if you have an object of the class you
expected at compile-time, you’re going to fall into a "not-a-duck"
scenario in the case of something like:
class String
undef_method :chomp
end
def some_method(a,b)
expect(a, String, b, Numeric) # I’m using your "Strong"Typing module. 
a.chomp #Whoops! “a” is not the duck you’re looking for
# (but it is a String)!
…etc.
end
Since I happen to be on the topic of your "Strong"Typing module, let’s
have a look at the FAQ:
# Wait N seconds, then open the bridge for M seconds
def sendMsg(bridge, n, m)
sleep(n)
bridge.open
sleep(m)
bridge.close
end
Now say ‘m’ is pased in as a string. Oops! A TypeError is
raised…
Bummer. I guess it’s only possible to do naive programming with Ruby.
I’m sure there are some Frankenstein-like mechanisms that could be
strapped onto ruby to get closer to this goal of "sophisticated"
programming, but I hope I don’t live to see them.
Chad (who suffers from this so-called “incorrect” thinking)
“Ryan Pavlik” rpav@mephle.com schrieb im Newsbeitrag
news:20030914014023.623ab4bb.rpav@mephle.com…
> Any yes, it's by no means specific to Ruby, but it is the way the > language defines a 'type'.No, it’s how you the programmer define a ‘type’. You have a few
options here; “duck typing” is just one of them. It has nothing to do
with what the languages specifies in this case.
But this is restricted by the language at hand. Because Ruby is the way
it is, you can decide whether to test an instance’s class or you don’t -
but this does not determine how Ruby defines a type. That is fixed by the
language. You can only decide how you “use” the type system. While in
Java - to name another popular language - you can’t - the compiler
enforces the type check for you. (Of course, if you use reflection it’s
another situation. But reflection is a special case.)
Regards
robert
On Sun, 14 Sep 2003 15:22:37 +0900 > Martin DeMello martindemello@yahoo.com wrote:
I’ve seen some adoption of the term among python people recently.
Regards,
Mark
On Saturday, September 13, 2003, at 04:01 PM, Michael Campbell wrote:
[snip]
Yes. You can do a lot of things with ruby that you can with other
languages; that it might have some ruby-cultural specific name isn’t
a new phenomenon, is it?
StrongTyping doesn’t address that problem, careful programming does:
def sendMsg(bridge, n, m)
open = false
begin
sleep n
bridge.open # either completes correctly or raises an exception before opening
open = true
sleep m
bridge.close
ensure
bridge.close if open
end
end
As Chad points out, even StrongTyping assumes that the interface of
a class will remain stable. This means that as long as methods can be
removed/modified, the notion of “type” enforced by StrongTyping doesn’t
match Ruby’s native one, so you cannot get 100% safety.
On Sun, Sep 14, 2003 at 07:19:07PM +0900, Chad Fowler wrote:
On Sun, 14 Sep 2003, Ryan Pavlik wrote:
class String
undef_method :chomp
enddef some_method(a,b)
expect(a, String, b, Numeric) # I’m using your "Strong"Typing module.
a.chomp #Whoops! “a” is not the duck you’re looking for
# (but it is a String)!
…etc.
endSince I happen to be on the topic of your "Strong"Typing module, let’s
Q: Yeah, but really, why bother? Why not just let ruby sort out the errors as they occur? A: This is incorrect thinking. Allowing errors to just occur when they happen is naive programming. Consider the following:
have a look at the FAQ:# Wait N seconds, then open the bridge for M seconds def sendMsg(bridge, n, m) sleep(n) bridge.open sleep(m) bridge.close end
–
_ _
__ __ | | ___ _ __ ___ __ _ _ __
'_ \ /| __/ __| '__ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
‘Ooohh… “FreeBSD is faster over loopback, when compared to Linux
over the wire”. Film at 11.’
– Linus Torvalds
What ? They stole that too ?? :>
Mark Wilson mwilson13@cox.net wrote:
I’ve seen some adoption of the term among python people recently.
–
Luc Heinrich - lucsky@mac.com
Luc Heinrich wrote:
I’ve seen some adoption of the term among python people recently.
What ? They stole that too ?? :>
I would claim independent invention, given that my post of Jul 2000
to c.l.py where I mused:
“”"
In other words, don’t check whether it IS-a duck: check
whether it QUACKS-like-a duck, WALKS-like-a duck,
etc, etc, depending on exactly what subset of duck-like
behaviour you need to play your language-games with. If
the argument fails this specific-ducklyhood-subset-test, then
you can shrug, ask “why a duck?” (at least, you can if you’re
a Marx Brothers fan and have memorized “Cocoanuts”’ script;
Monty Python one-true-wayists will have to find their own
simile here), and move on to the next set of tests (why-a-no-
chicken immediately comes to mind, but then one would have
to ask why it crosses the road, so I think we’d better snip it).
“”"
was done before I had ever heard of Ruby, and explained as
“”"
My instinctive approach (and it may be that I still haven’t
developed the “right” Python instincts, because I haven’t
been using it long!)
“”"
while the first mention I can find in comp.lang.ruby is in
a Jan 2001 post by Ben Tilly:
“”"
Imagine a language where you are constantly telling the
language everywhere that you have a duck because it is
walking like a duck and talking like a duck. This is
built into everything that you do. Then suddenly you
find out that it isn’t really a duck after all.
“”"
Of course, it’s quite possible that Google Groups’ archive
is incomplete for either or both languages.
Alex
Mark Wilson mwilson13@cox.net wrote:
Alex Martelli wrote:
If
the argument fails this specific-ducklyhood-subset-test, then
you can shrug, ask “why a duck?” (at least, you can if you’re
a Marx Brothers fan and have memorized “Cocoanuts”’ script;
Monty Python one-true-wayists will have to find their own
simile here), […]
I wonder whether Python people will revert to witch-typing, since it
lends itself so nicely to comparision with duck-typing. 
Not to mention varieties of other old classics:
–
([ Kent Dahl ]/)_ ~ [ Kent Dahl - Kent Dahl ]/~
))_student_/(( _d L b_/ (pre-) Master of Science in Technology )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
It would not be the first time I was wrong.
Regards,
Mark
On Sunday, September 14, 2003, at 11:43 AM, Alex Martelli wrote:
Mark Wilson mwilson13@cox.net wrote:
I’ve seen some adoption of the term among python people recently.
I would claim independent invention, given that my post of Jul 2000
to c.l.py where I mused:
“”"
[snip]
“”"was done before I had ever heard of Ruby, and explained as
“”"
[snip]
while the first mention I can find in comp.lang.ruby is in
a Jan 2001 post by Ben Tilly:
“”"
[snip]“”"Of course, it’s quite possible that Google Groups’ archive
is incomplete for either or both languages.
