I promised myself I'd shut-up for awhile, maybe I still should, but I
just couldn't help myself with this one...
Today I wrote
data = data.transform
but I meant to write
data = transform(data)
While I knew data would be hash, I certainly didn't want to write a new
Hash method just for this --you reserve extensions for really general
reusable stuff, right? Besides I wanted to remain open to duck typing
and hence any hash-like object.
That's when it hit me. We haven't yet taken the full duck type plunge.
We've just strapped a quasi-duck onto an old oop type dog. We're still
defining our methods base on types, not duck types. But what would
defining on duck type mean intead? As it turns out it measn defining on
method dependencies.
Take #transform. Forget what "class" it belongs to. What does it do?
For the sake of this dialog lets say it does this:
def transform
data.to_a
end
Simple. Now, if I want to call #transform on data, all it needs to do
is repond_to #to_a. It need not matter at all what class it is. So
imagine if you will, that instead of "classes" and "methods", we could
define "ducks" and "quacks".
duck to_a
quack transform
self.to_a
end
end
Now anything that responded to #to_a could use #transform. I'm not sure
how far this can be taken. Can classes be undone altogegther? But in
anycase, it seems very cool, and I wonder what kind of overall effect
it could have on coding?
T.
on 2006-07-24 01:12
on 2006-07-24 04:42
duck == mixin Consider the Enumerable mixin. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand Carter's Clarification of Murphy's Law. "Things only ever go right so that they may go more spectacularly wrong later." From this principle, all of life and physics may be deduced.
on 2006-07-24 04:45
On Mon, 24 Jul 2006 08:09:58 +0900, transfire@gmail.com wrote: >Now anything that responded to #to_a could use #transform. I'm not sure >how far this can be taken. Can classes be undone altogegther? But in >anycase, it seems very cool, and I wonder what kind of overall effect >it could have on coding? there's a language called "self" that has no classes, only prototypes. if you can find some material on that, i think you'll find it interesting. regards,
on 2006-07-24 05:01
I much prefer its (less mature) derivative, Io. Everything is a message to something else, and everything is a prototype. Very simple, very powerful (even, dare I say, more powerful than Ruby, albeit a bit less pretty). - Jake McArthur
on 2006-07-24 05:10
Jake McArthur wrote: > I much prefer its (less mature) derivative, Io. Everything is a > message to something else, and everything is a prototype. Very simple, > very powerful (even, dare I say, more powerful than Ruby, albeit a bit > less pretty). > > - Jake McArthur Actual, real programming languages with compilers or interpreters, a code base, applications and vibrant communities are for wimps! Give me an academic abstract language like the Pi-Calculus any day! :) Now that I think of it, Lisp was once an academic abstract language ... some bozo had to spoil it by writing an interpreter for the IBM 704. Speaking of languages, isn't FORTRAN 50 years old this year?
on 2006-07-24 05:13
On Monday 24 July 2006 11:40, John Carter wrote: > duck == mixin > > Consider the Enumerable mixin. > Well... i don't think mixins are exactly that :) what trans proposes is more like excessive duck-typing imagine a duck you can make it quack and you know - what the duck quacks can be processes in many ways... Duck.quack.record.to_tape.copy.to_cd.send_to producer might be a bit excessive, but in essential that's it... i've learned that kind of 'method' in Dylan, where you define that stuff a bit different - you have a kind of reversed dispatcher that adds classes to methods and decides which method to use given what object you operate on. little syntax help - the stuff in <> are classes, <duck> and <fish> are subclasses of <animal> ######################################## define method to-s (animal :: <animal>) color(animal) end define method color (duck :: <duck>) "brown" end define method color (fish :: <fish>) "grey" end ######################################## the methods are not added to the object - they look like that afterwards: (using ruby for that, so it looks a bit nicer ;) def color (x) if x === Animal if x === Fish "grey" elsif x === Duck "brown" end end end don't want to hang around in dylan for too long, but this was a new way (at least for me) to express methods... now, this could be driven further you could attach methods to objects that respond to specific methods ######################################## methods to_a def compact delete_if{|e| e.nil? } end def sum inject{|s,v| s+v} end end class Foo def to_a [1,2,3,nil] end end Foo.new.compact.sum # 6 ######################################## something like that... i find that is true ducktyping :) however... the beauty is in the eye of the beholder, so it might look butt-ugly to someone else :| i just kinda like the idea itself - the implementation in ruby would be enormous work (as i imagine it at least) - and would slow down ruby further... these assumptions are just in my honest opinion :) might as well be pretty neat to integrate and work with... but i have my doubts...
on 2006-07-24 10:59
On 7/24/06, transfire@gmail.com <transfire@gmail.com> wrote: > > I promised myself I'd shut-up for awhile, maybe I still should, but I > just couldn't help myself with this one... So did I ;) Today I wrote > > data = data.transform > > but I meant to write > > data = transform(data) > > While I knew data would be hash, I certainly didn't want to write a new > Hash method just for this --you reserve extensions for really general > reusable stuff, right? I fail to see this point at 100%, I think this is what subclassing is for, but I am really oppused to ducktyping, one needs to be, I am afraid of things all agree on. Well I love ducktyping but I call it protcolling and I want early checking, and I seem to be alone. Sorry if I go offtopic. Besides I wanted to remain open to duck typing > and hence any hash-like object. Yeah great, you see that is what troubles me, it is completely cool to talk about hash-like object, but what is a hash-like object? Which messages must a hash-like object respond to? All of Hash, I suppose, thus a subclass, or only some, then we can talk about protocols again, but the failure to be able to define the protocol just worries me. Again very important: The failure to be able, not to have to, I am 100% for the enabeling approach, but who enables constraints and protocol checking? That's when it hit me. We haven't yet taken the full duck type plunge. Good! We've just strapped a quasi-duck onto an old oop type dog. Poor animal. We're still > defining our methods base on types, not duck types. This duck risks to get bitten into it's tail, by itself. I have the feeling that method delegation (was this the english name (patrimoine de méthode)?) is all you are doing. But pleas get me straight if I read you wrong. But what would > defining on duck type mean intead? As it turns out it measn defining on > method dependencies. > > Take #transform. Forget what "class" it belongs to. What does it do? > For the sake of this dialog lets say it does this: I am losing you there :( > def transform > data.to_a > end > > Simple. Well if you say so ;) Now, if I want to call #transform on data, all it needs to do > Now anything that responded to #to_a could use #transform. I'm not sure > how far this can be taken. Can classes be undone altogegther? But in > anycase, it seems very cool, and I wonder what kind of overall effect > it could have on coding? Is this a protocol you try to define, sorry if I am too stupid to get it, could you explain to an old dog, as a friendly duck? T. > > > Cheers Robert -- Deux choses sont infinies : l'univers et la bêtise humaine (j'y suis, j'y reste); en ce qui concerne l'univers, je n'en ai pas acquis la certitude absolue. - Albert Einstein
on 2006-07-24 11:47
> T.
Like this *evil grin* ? (Ok, there are still classes...)
------------------------------------------------------------------------
----
class Object
def method_missing sym, *args
@@ducks.select{|d| d.first == sym}.each do |duck|
return send(duck[1], *args) if duck.last.all?{|i|
respond_to? i}
end
super
end
def self.duck sym, real , *interface
(@@ducks ||= []) << [sym, real, interface]
end
end
def i_next_to_s
succ.to_s
end
def f_next_to_s
ceil.to_s
end
Object.duck :next_to_s, :i_next_to_s, :succ, :to_s
Object.duck :next_to_s, :f_next_to_s, :ceil, :to_s
p(41.next_to_s) #=> "42"
p('A'.next_to_s) #=> "B"
p(5.5.next_to_s) #=> "6"
------------------------------------------------------------------------
----
cheers
Simon
on 2006-07-24 11:50
Robert Dober wrote: > On 7/24/06, transfire@gmail.com <transfire@gmail.com> wrote: <snip> >> and hence any hash-like object. > > Yeah great, you see that is what troubles me, it is completely cool to talk > about hash-like object, but what is a hash-like object? Which messages > must > a hash-like object respond to? All of Hash, I suppose, thus a subclass, or > only some, then we can talk about protocols again, but the failure to be > able to define the protocol just worries me. That's the whole point. Duck-typing means that your class only needs to define the methods (of Hash, in this case) that the called method (transform here) needs, *not* the whole Hash class, *without* having to specify a protocol. If you want to specify a protocol, there's one example of how to do it here: http://www.erikveen.dds.nl/monitorfunctions/index.html#6.0.0 > Again very important: The failure to be able, not to have to, I am 100% for > the enabeling approach, but who enables constraints and protocol checking? See above. Second time I've used that link in this thread :-)
on 2006-07-24 12:03
> Now anything that responded to #to_a could use #transform. I'm not sure > how far this can be taken. Can classes be undone altogegther? But in > anycase, it seems very cool, and I wonder what kind of overall effect > it could have on coding? :) I was thinking things like this a while ago, and a clever friend pointed me to predicate classes (see google). The idea with them is that you define a predicate such as "supports the method 'each'". You could call this predicate Enumerable. The predicate is a declaration of your interface requirements. You can then add methods to this Enumerable predicate class, such as min, max, inject, etc. From then, anything that is Enumerable will also support the things you put in to Enumerable. Pretty cool. I liked the idea, anyway. I like it because I think it would make it easier to take things that you've already got, things that someone has given to you perhaps, and say new things about them based on the fact that they've pretty much got the interface you're looking for (if they don't quite have the right interface, you can use predicate classes to give them the additional "glue" that they need). I also like it because I don't think that there's anything especially fundamental about classes. With predicate classes, all you're really saying is that "if I've got something that can do x and y, then I know that I can equally validly think of it as something that can do z". [I should point out here that I don't imagine Predicate Classes are "the answer"; I'm just pointing to them as being interesting.] Class hierarchies almost always seem arbitrary and task oriented to me. That works well when you've a particular task in mind, but I think it falls over when the task changes, or when you're more interested in the information in some objects, rather than what they are currently being used for. I also think they're an impediment to being agile because you're building up a hierarchy that may not exist. Sure, you can refactor, and perhaps you've got automated tools that do that, but you shouldn't need to. You, and any part of your program or someone else's, ought to be able to look at some existing objects in any way they choose. You should be able to say anything you like about your particular way of looking at those things. While I like Ruby a great deal (and I really mean that: it's made programming fun again, for me), I don't think contemporary OO is all that. Something that's wonderful about Ruby though, is that I think it's got every chance of being the platform in which people find that out, and find a better way. On the other hand, I could be wrong, in which case Ruby's already there :) Cheers, Benjohn
on 2006-07-24 12:31
On 7/24/06, Alex Young <alex@blackkettle.org> wrote: > > a hash-like object respond to? All of Hash, I suppose, thus a subclass, > or > > only some, then we can talk about protocols again, but the failure to be > > able to define the protocol just worries me. > That's the whole point. Duck-typing means that your class only needs to > define the methods (of Hash, in this case) that the called method > (transform here) needs, *not* the whole Hash class, *without* having to > specify a protocol. If you want to specify a protocol, there's one > example of how to do it here: > > http://www.erikveen.dds.nl/monitorfunctions/index.html#6.0.0 Well I have read that, kind of, it is a little bit heavy, too heavy I am afraid. I still do not get the point, are you saying I am right (let dogs life) or are you saying I am wrong (let only ducks life). Mixins are another nice way to think about it class Dog include Duck ... # no this is *not* the Perl6 Thingy Jabbawalky operator ;) end d = Puppet d.implements? Duck ==> true but maybe this is here already, gotta check. Thx for your considerations I repeat nevertheless Ducks are great, unless they kill Dogs ;) Cheers Robert > Again very important: The failure to be able, not to have to, I am 100% > for > > the enabeling approach, but who enables constraints and protocol > checking? > See above. Second time I've used that link in this thread :-) I will not blame you, yet ;)
on 2006-07-24 12:59
Robert Dober wrote: >> > about hash-like object, but what is a hash-like object? Which messages >> example of how to do it here: >> >> http://www.erikveen.dds.nl/monitorfunctions/index.html#6.0.0 > > > > Well I have read that, kind of, it is a little bit heavy, too heavy I am > afraid. > I still do not get the point, are you saying I am right (let dogs life) or > are you saying I am wrong (let only ducks life). It's my opinion that opposition to duck-typing is a bad idea (especially when dealing with Ruby, given how pervasive it is), but that doesn't make it wrong. It is perfectly possible for both dogs and ducks to co-exist. > Mixins are another nice way to think about it > > class Dog > include Duck > ... # no this is *not* the Perl6 Thingy Jabbawalky operator ;) > end > > d = Puppet > d.implements? Duck ==> true If you're always supplying Duck's functionality as a mixin, you can do: Duck === d => true The beauty of duck-typing is that you don't have to, though. If you wanted an Object#implements? method which doesn't rely on implementation via mixin, you could do it like this: class Object def implements?(module) my_methods = Set.new(self.public_methods) module_methods = Set.new(module.instance_methods) return my_methods.superset?(module_methods) end end Again, that misses the point somewhat, though - duck-typing lets you not have to think about the concept of a defined interface (in the Module sense, at least). If your method only calls #foobar on a passed object, then that object only need respond to the #foobar method. > but maybe this is here already, gotta check. > Thx for your considerations > I repeat nevertheless > Ducks are great, unless they kill Dogs ;) You can always check the class of an object, and there are ways to make the syntax less cumbersome than it might otherwise be.
on 2006-07-24 13:46
On 7/24/06, Alex Young <alex@blackkettle.org> wrote: > >> > Yeah great, you see that is what troubles me, it is completely cool > >> > able to define the protocol just worries me. > > > > Mixins are another nice way to think about it > Duck === d > => true No that is not what I want (I do that an awful lot but that is very doggish) As a matter of fact I want to be ducky, but on the save side. I'll explain module A def a; "a"; end def b; "b", end end class DogOne include A end class DogTwo def a; :a; end def b; :b; end end [DogOne.new, DogTwo.new].map{ |doggy| doggy.implement? A} ==> [true, true] ==== As a matter of fact I am completely in love with ruby and even with ducktyping, but I am terribly in need of *early* failure. I want to fail my programs as early as possible e.g. def eat ( someAniamal) .... someAnimal.a ===> error is bad (for me, but early failure is a well accpted principle) while def eat( somaAniaml) assure someAnimal.implements? A is better In other words, yes I love to use Dogs but when I use Ducks (and there are very good reasons to use Ducks, e.g. agile development) I want to get to know my duck fast. The beauty of duck-typing is that you don't have to, though. Yes I agree 100% but the not-so-beauty is that I cannot (veryeasily) If you wanted an Object#implements? method which doesn't rely on > implementation via mixin, you could do it like this: > > class Object > def implements?(module) > my_methods = Set.new(self.public_methods) > module_methods = Set.new(module.instance_methods) > return my_methods.superset?(module_methods) > end > end yes I could, why not, nice idea Again, that misses the point somewhat, though - duck-typing lets you not > have to think about the concept of a defined interface (in the Module > sense, at least). If your method only calls #foobar on a passed object, > then that object only need respond to the #foobar method. Is this really a feature, all the times, I do not think so. > Thx again for your thaughts Robert
on 2006-07-24 13:59
Robert Dober wrote: > On 7/24/06, Alex Young <alex@blackkettle.org> wrote: <snip> >> def implements?(module) >> my_methods = Set.new(self.public_methods) >> module_methods = Set.new(module.instance_methods) >> return my_methods.superset?(module_methods) >> end >> end > > yes I could, why not, nice idea I think it does everything you're after. > > Again, that misses the point somewhat, though - duck-typing lets you not > >> have to think about the concept of a defined interface (in the Module >> sense, at least). If your method only calls #foobar on a passed object, >> then that object only need respond to the #foobar method. > > Is this really a feature, all the times, I do not think so. Absolutely. It's what makes the entire Enumerable module so useful. Every single Enumerable method works that way - the object only has to support the #each method for all of Enumerable's methods to be applicable. The #to_s method is similar - anything that supports #to_s has a whole raft of functionality available to it because methods know that they've got a way of treating it as a string.
on 2006-07-24 14:06
Hi -- On Mon, 24 Jul 2006, Alex Young wrote: > If you're always supplying Duck's functionality as a mixin, you can do: > > Duck === d > => true > > The beauty of duck-typing is that you don't have to, though. I'd go further: the definition of duck typing is that you don't :-) I think Dave Thomas was always pretty explicit about saying that duck typing, in practice as well as theory, is something one does *instead* of checking class/module ancestry. I think the use of Duck, duck, quack, etc. as class and method names is kind of misleading. It moves the class-checking approach into the "duck" namespace -- which means that "duck typing" gets redefined, and it also means that the thing originally called "duck typing" is left without a name. What it always comes down to for me is this: in Ruby, at the moment that you send a message to an object, you send a message to an object. No amount of checking of class membership -- not even, technically, the prior checking of respond_to? -- has any bearing on what happens when that message is sent. Duck typing is Dave's name for an approach to Ruby programming that attempts to live in harmony with this underlying state of things in Ruby, rather than covering it up or pretending it isn't there. There are two major ramifications of duck typing: 1. it leads you to understand what's actually happening every time you call a method in Ruby; 2. it points the way to interesting and productive things you can do to harness the way Ruby works, rather than fighting it. I've always agreed with Jim Weirich that Ruby is "a duck-typed language". In other words, as far as Ruby is concerned, everyone is duck typing: everyone is sending messages to objects, and those message-sending events are never connected directly to an object's ancestry. Hence #1 in the list above. As for #2 -- it's not that it's a mark of shame to use #is_a? and #respond_to?, but rather that Ruby does provide a programming environment in which it's possible, thanks to a design that eschews certain constraints, to do otherwise, with good results. Final note to Alex: much of what's here is in response to the whole thread, even though it's in a response to your post :-) David
on 2006-07-24 14:45
On Jul 23, 2006, at 10:59 PM, Jake McArthur wrote: > I much prefer its (less mature) derivative, Io. Everything is a > message to something else, and everything is a prototype. Very > simple, very powerful (even, dare I say, more powerful than Ruby, > albeit a bit less pretty). > > - Jake McArthur You piqued my curiosity with that. But "lo" is really hard to google for. Do you have any reference links? -Mat
on 2006-07-24 14:46
On 7/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote: > > The beauty of duck-typing is that you don't have to, though. > > I'd go further: the definition of duck typing is that you don't :-) Maybe we can fly. Maybe. But I do not believe so. It just strikes me as if the community is throwing away so much by being, forgive me to be blunt, intolerant about philosophies that are well known, like early failing. Although I said intolerant I want to add immediately that they are nicely so, but quite firmely. I think Dave Thomas was always pretty explicit about saying that duck > typing, in practice as well as theory, is something one does *instead* > of checking class/module ancestry. I think the use of Duck, duck, > quack, etc. as class and method names is kind of misleading. It moves > the class-checking approach into the "duck" namespace -- which means > that "duck typing" gets redefined, and it also means that the thing > originally called "duck typing" is left without a name. I have to say sorry though about this one, I completely lost the original topic in my holy war, good you pointed it out! [Snip ] > Slashdot, 7/12/2006!) > http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log > dblack@wobblini.net => me > > Cheers Robert -- Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui concerne l'univers, je n'en ai pas acquis la certitude absolue. - Albert Einstein
on 2006-07-24 14:55
Robert Dober wrote: <snip> > Maybe we can fly. Maybe. But I do not believe so. > It just strikes me as if the community is throwing away so much by being, > forgive me to be blunt, intolerant about philosophies that are well known, > like early failing. > Although I said intolerant I want to add immediately that they are nicely > so, but quite firmely. Duck typing doesn't stop you from failing early. If you combine the #implements? method with the monitor-functions example from earlier in the thread, you've got quite a nice interface checker. You can have your duck and eat it too.
on 2006-07-24 14:56
> You piqued my curiosity with that. But "lo" is really hard to google > for. Do you have any reference links? Actually it is pretty easy to google: Io programming language ;) http://www.iolanguage.com/about/ Regards, Rimantas
on 2006-07-24 14:56
Mat Schaffer wrote: > > You piqued my curiosity with that. But "lo" is really hard to google > for. Do you have any reference links? http://www.iolanguage.com/about/
on 2006-07-24 15:09
On Jul 24, 2006, at 8:52 AM, Rimantas Liubertas wrote: >> You piqued my curiosity with that. But "lo" is really hard to google >> for. Do you have any reference links? > > Actually it is pretty easy to google: Io programming language ;) > > http://www.iolanguage.com/about/ Right. io, not LO..... silly sans-serif fonts. Thanks! -Mat
on 2006-07-24 15:39
On 7/24/06, Alex Young <alex@blackkettle.org> wrote: > nicely > > so, but quite firmely. > Duck typing doesn't stop you from failing early. If you combine the > #implements? method with the monitor-functions example from earlier in > the thread, you've got quite a nice interface checker. > > You can have your duck and eat it too. Nice 1. -- > Alex > > Ah sorry I had the impression some are fairly opposed to that approach and considered it unrubyfull. Maybe I am too *sensible*. -- Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui concerne l'univers, je n'en ai pas acquis la certitude absolue. - Albert Einstein
on 2006-07-24 15:46
Hi -- On Mon, 24 Jul 2006, Robert Dober wrote: >> > Although I said intolerant I want to add immediately that they are > > -- >> Alex >> >> > Ah sorry I had the impression some are fairly opposed to that approach and > considered it unrubyfull. Maybe I am too *sensible*. I don't think I'd call interface-checking "duck typing", but if it helps you build the program you want, then you should probably do it. David
on 2006-07-24 15:57
> You piqued my curiosity with that. But "lo" is really hard to google > for. Do you have any reference links? > -Mat http://www.iolanguage.com/ Enjoy ;)
on 2006-07-24 19:27
benjohn@fysh.org wrote: > I also like it because I don't think that there's anything especially > fundamental about classes. With predicate classes, all you're really > saying is that "if I've got something that can do x and y, then I know > that I can equally validly think of it as something that can do z". The concept really piqued my interest, and since ruby gives us such nice metaprogramming abilities, why not do it? module DuckTyping @@quacks = Hash.new{ |h,k| h[k] = {} } def ducktype(*reqs, &block) o = Object before = o.methods o.class_eval(&block) after = o.methods for methodname in (after - before) @@quacks[methodname.to_sym][reqs] = o.instance_method(methodname.to_sym) o.send(:remove_method, methodname.to_sym) end end def ducktype_method(methodname) @@quacks[methodname.to_sym].each do |reqs, m| if reqs.all?{ |r| self.respond_to?(r) } return m end end return nil end def method_missing(methodname, *args, &block) if m = ducktype_method(methodname) m.bind(self).call(*args, &block) else super end end end Object.module_eval{ include DuckTyping } ducktype :quack do def quack_loudly quack.upcase end end class Duck def quack "quack!" end end class Dog def bark "woof!" end end Duck.new.quack_loudly #=> "QUACK!" Dog.new.quack_loudly #=> NoMethodError nifty?
on 2006-07-24 19:50
Daniel DeLorme wrote: > @@quacks = Hash.new{ |h,k| h[k] = {} } [snip cool code] > end > > > nifty? Nicely done! Code worthy of experimentation. A lot of excellent comments in this thread too. I wonder then, if we take up John Carter's notion on duck as mixin, then Enumerable can be defined as: ducktype :each do def collect each{ |e| yield(e) } end ... end Although clearly the distinction between a mixin and a ducktype is the ducktypes global influence. Quite powerful! Yet, I do imagine that with this is place someone would call for selector namepsaces to reign in the abundant flocks ;) Onefurther step would have to be taken, at the very least. a means of constraining them to specific scopes. Perhaps that's a simple as limiting them the module space they are defined in? In any case very interesting. I really wonder just how far one can take this shift in paradigm? T.
on 2006-07-24 22:38
Hi -- On Tue, 25 Jul 2006, Daniel DeLorme wrote: > module DuckTyping > @@quacks = Hash.new{ |h,k| h[k] = {} } [...] > Duck.new.quack_loudly #=> "QUACK!" > Dog.new.quack_loudly #=> NoMethodError I guess you'd have to think of a new name to refer to what has in the past been called "duck typing" :-) David
on 2006-07-24 22:50
Hi -- On Tue, 25 Jul 2006, transfire@gmail.com wrote: > Although clearly the distinction between a mixin and a ducktype is the > ducktypes global influence. Quite powerful! Yet, I do imagine that with > this is place someone would call for selector namepsaces to reign in > the abundant flocks ;) Onefurther step would have to be taken, at the > very least. a means of constraining them to specific scopes. Perhaps > that's a simple as limiting them the module space they are defined in? > > In any case very interesting. I really wonder just how far one can take > this shift in paradigm? If it's a shift in paradigm, then it isn't "duck typing" (which is a term invented to describe aspects of programming in Ruby). Please choose a different animal :-) David
on 2006-07-24 22:57
On Tue, Jul 25, 2006 at 05:48:29AM +0900, dblack@wobblini.net wrote: > > If it's a shift in paradigm, then it isn't "duck typing" (which is a > term invented to describe aspects of programming in Ruby). > > Please choose a different animal :-) The term "duck typing" predates Ruby, as I recall. I seem to remember it being applied to Objective-C, for instance. . . . not that anyone outside of NeXT used Objective-C for most of its existence.
on 2006-07-24 23:03
Hi -- On Tue, 25 Jul 2006, Chad Perrin wrote: > . . . not that anyone outside of NeXT used Objective-C for most of its > existence. I've always thought that Dave Thomas coined it, and that it then caught on (including outside of Ruby). Either way -- I think that using "duck" in method and class names dilutes the meaning of "duck typing", and also does a disservice to the stuff people are writing, some of which may be quite interesting. When I see these prototype-style libraries named "duck" this and that, I'm just aware 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. David
on 2006-07-25 00:47
On Tue, Jul 25, 2006 at 06:01:45AM +0900, dblack@wobblini.net wrote: > using "duck" in method and class names dilutes the meaning of "duck > typing", and also does a disservice to the stuff people are writing, > some of which may be quite interesting. When I see these > prototype-style libraries named "duck" this and that, I'm just aware > 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. You may well be right. I'm afraid I'm not an expert in the etymology of the term "duck typing". I'll take your word for it, for the time being.
on 2006-07-25 00:50
Daniel DeLorme wrote: > module DuckTyping > o.instance_method(methodname.to_sym) > return nil > Object.module_eval{ include DuckTyping } > def quack > Duck.new.quack_loudly #=> "QUACK!" > Dog.new.quack_loudly #=> NoMethodError > > > nifty? Isn't this stuff used i Aspect Oriented Programming as well? I only know what I've read in the RCR, so I'm not sure. Cheers, Daniel
on 2006-07-25 03:24
dblack@wobblini.net wrote: > I've always thought that Dave Thomas coined it, and that it then > caught on (including outside of Ruby). Either way -- I think that > using "duck" in method and class names dilutes the meaning of "duck > typing", and also does a disservice to the stuff people are writing, > some of which may be quite interesting. When I see these > prototype-style libraries named "duck" this and that, I'm just aware > 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. This argument has been made before, notably by you, and it simply does not hold-up to scrutiny. First of all, how can a programming language do anything that does not arise from implementation. That's completely contradictory. But I'll take that to be a misstatement, and you actually just mean that duck-typing is not something you explicitly declare, but rather is an implicit occurance of not imposing type restrictions on method arguments. However you are wrong to think that there is no imposition being made at all. When an object is the receiver of a message to which it does not respond, it readily object with a resulting NoMethodError. So disavowing #respond_to? as antithetical to duck-typing is simply delusional. Explicit is just the otherside of the implicit coin. Defining a set of methods based on a conformity to a "duck type" is therefore not contrary to the original coinage, but in reality furthers it by taking into account all side. Which is what I was saying with my original post, that the "duck" concept as currently implemented may yet be only half turned. It would then be clear that your hold to this specific idea of the inexpressibility of a duck type is effective only at stymieing innovation in the area. T.
on 2006-07-25 05:36
I think that AOP is a much more specific approach tailored for particular types of problems in particular types of OO applications where the the classes can't be separated nicely. AspectR looks to me (on the surface) to have more in common with Erik Veenstra's wrap_method() routine, linked to earlier in the thread.
on 2006-07-25 06:07
I'm not sure what the best place for this is; sorry. The following are my views: What we know as 'duck typing' is not really a programming paradigm, but a set practices as Mr. Black says--merely the "yin" end of the type-checking continuum. I first learned about it, although of course not by that name, from studying C++ templates, where also the prevailing wisdom is that you shouldn't assume anything more about your library's client's code than is absolutely necessary. The 'duck typing' moniker that marks it as a novelty is most useful against the background of static languages, where type-checking helps prevent runtime errors. For Ruby, where *every* error is runtime, duck typing is the raw form of its behavior, and should be recognized as quickly as possible, because it isn't always good. At its utmost, duck typing is the total absence of validation. You are saying that nothing about your client's program is worth trying to predict, that 'if it works, it works,' and if it doesn't, he'll know because it just blew up. Hmm. I see where type-checking came from. As far as Ruby best practices go, I think 'duck typing' just means using respond_to?() more than kind_of?() and include?(). If you really wanted to, dumping class use entirely and turning Ruby into a prototype-based language wouldn't be too hard: you'd use Object::new() only, define only singleton methods, and extend objects with clone(); and if you wanted to delegate, you'd keep an array of references of "parent" objects, Perl-style. Personally, I feel that Ruby needs more, rather than less, type safety, to balance its natural inclination otherwise and because no amount of 'duck typing' disaffirms that erroneous behavior is best caught as soon as possible. But I don't think anyone would advocate a return to rigid inheritance checking, which realization the deprecation of type() notably indicates.
on 2006-07-25 06:07
Hi -- On Tue, 25 Jul 2006, 7rans wrote: >> code, and that therefore the point of this code is being obscured >> rather than revealed by the naming. > > This argument has been made before, notably by you, and it simply does > not hold-up to scrutiny. First of all, how can a programming language > do anything that does not arise from implementation. That's completely > contradictory. But I'll take that to be a misstatement, and you > actually just mean that duck-typing is not something you explicitly > declare, but rather is an implicit occurance of not imposing type > restrictions on method arguments. 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 Thomas 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. > then be clear that your hold to this specific idea of the > inexpressibility of a duck type is effective only at stymieing > innovation in the area. 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). David
on 2006-07-25 06:23
Hi -- On Tue, 25 Jul 2006, Dumaiu wrote: > runtime errors. For Ruby, where *every* error is runtime, duck typing > is the raw form of its behavior, and should be recognized as quickly as > possible, because it isn't always good. At its utmost, duck typing is > the total absence of validation. You are saying that nothing about > your client's program is worth trying to predict, that 'if it works, it > works,' and if it doesn't, he'll know because it just blew up. True, though that's partly why test-driven development is so big among Rubyists. > Hmm. I see where type-checking came from. As far as Ruby best > practices go, I think 'duck typing' just means using respond_to?() more > than kind_of?() and include?(). 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?....) > If you really wanted to, dumping class > use entirely and turning Ruby into a prototype-based language wouldn't > be too hard: you'd use Object::new() only, define only singleton > methods, and extend objects with clone(); and if you wanted to > delegate, you'd keep an array of references of "parent" objects, > Perl-style. 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. > Personally, I feel that Ruby needs more, rather than less, type > safety, to balance its natural inclination otherwise and because no > amount of 'duck typing' disaffirms that erroneous behavior is best > caught as soon as possible. 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. > But I don't think anyone would advocate a > return to rigid inheritance checking, which realization the deprecation > of type() notably indicates. 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. David
on 2006-07-25 06:26
On Tue, 2006-07-25 at 02:49 +0900, transfire@gmail.com wrote: >From the code above, this appears to be going in the direction of formal 'interface' concept. If 'each' is a "ducktype", and 'each' has a set of well defined methods, except for the fact that code exists in those methods, this is tantamount to publishing an interface. >From the little that I understand, the whole concept of duck typing is about *not* being concerned with a full published interface (or, a full published inheritance) of the receiver; rather, we are only concerned with whether the receiver answers the _current_ message. I could be wrong in understanding your code example, though! Greetings, JS
on 2006-07-25 11:38
dblack@wobblini.net wrote: > I've always thought that Dave Thomas coined it, and that it then > caught on (including outside of Ruby). Either way -- I think that > using "duck" in method and class names dilutes the meaning of "duck > typing", and also does a disservice to the stuff people are writing, > some of which may be quite interesting. When I see these > prototype-style libraries named "duck" this and that, I'm just aware 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. > 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. Daniel
on 2006-07-25 13:16
Ron Jeffries <ronjeffries@acm.org> writes: > On Mon, 24 Jul 2006 08:09:58 +0900, transfire@gmail.com wrote: > >>Now anything that responded to #to_a could use #transform. I'm not sure >>how far this can be taken. Can classes be undone altogegther? But in >>anycase, it seems very cool, and I wonder what kind of overall effect >>it could have on coding? > > there's a language called "self" that has no classes, only prototypes. if you > can find some material on that, i think you'll find it interesting. While you're at it, have a look at Slate, that also removes single-dispatch.
on 2006-07-25 13:50
dblack@wobblini.net 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 Thomas 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 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). 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.
on 2006-07-25 14:28
Hmmm... David, my point is simply this: I understand your concern with regards to the intended coinage of "duck typing" by Dave Thomas. 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.
on 2006-07-25 14:39
Daniel 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?
on 2006-07-25 14:42
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.'
-J
on 2006-07-25 15:36
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 Fowler, 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
on 2006-07-25 16:19
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
@@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?(r) }
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!"
on 2006-07-25 16:39
dblack@wobblini.net wrote: > Hi -- > > On Tue, 25 Jul 2006, Daniel DeLorme wrote: > > > dblack@wobblini.net 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.
on 2006-07-25 16:45
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.
on 2006-07-25 17:48
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
on 2006-07-25 18:17
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. 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 2006-07-25 18:54
Phil Tomson 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 2006-07-25 19:12
On Wed, 26 Jul 2006, Phil Tomson 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: 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 2006-07-25 20:18
On Wed, 26 Jul 2006, ara.t.howard@noaa.gov 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
on 2006-07-25 22:55
dblack@wobblini.net 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" :-) 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. > 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. > Oh, really? Thanks for setting me straight.
on 2006-07-25 23:16
On 25 Jul 2006, at 05:06, dblack@wobblini.net 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 :-) 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.
on 2006-07-25 23:32
On Wed, 26 Jul 2006 dblack@wobblini.net 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 > :-) 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
on 2006-07-25 23:35
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).
on 2006-07-25 23:38
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. 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
on 2006-07-26 02:32
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
on 2006-07-26 02:52
Phil Tomson 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
on 2006-07-26 02:56
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
on 2006-07-26 03:05
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
on 2006-07-26 03:36
Hal Fulton 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 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
on 2006-07-26 03:39
On Wed, Jul 26, 2006 at 10:33:12AM +0900, James Britt 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 2006-07-26 03:42
James Britt 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 2006-07-26 05:46
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". 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 2006-07-26 06:36
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: ...
on 2006-07-26 06:49
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' ;-) Zen Typing: The sound of one duck quacking.
on 2006-07-26 07:11
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.
on 2006-07-26 07:11
Gregory Brown wrote:
...
> Zen Typing: The sound of one duck quacking.
No, really, what *is* the sound of a duck typing?
on 2006-07-26 07:15
On Wed, Jul 26, 2006 at 01:48:39PM +0900, Gregory Brown wrote: > 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' ;-) > > Zen Typing: The sound of one duck quacking. Shouldn't that be "the sound of one wing flapping"?
on 2006-07-26 07:19
On Wed, 26 Jul 2006, Gregory Brown wrote: > 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' ;-) > > Zen Typing: The sound of one duck quacking. touche! -a
on 2006-07-26 08:07
Chad Perrin 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 2006-07-26 09:15
On Jul 25, 2006, at 10:43 PM, ara.t.howard@noaa.gov 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.
- Jake McArthur
on 2006-07-26 10:01
On Jul 26, 2006, at 8:13, Jake McArthur wrote:
> let's-make-everything-twice-as-confusing.
Surely AJAX already took that award?
on 2006-07-26 14:47
Hi -- On Wed, 26 Jul 2006, ara.t.howard@noaa.gov 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 Thomas 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
on 2006-07-26 16:51
ara.t.howard@noaa.gov 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 2006-07-26 16:58
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 Weirich 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
on 2006-07-26 17:08
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 2006-07-26 17:14
On Wed, 26 Jul 2006 dblack@wobblini.net 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 Thomas 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
on 2006-07-26 17:21
Hi -- On Thu, 27 Jul 2006, ara.t.howard@noaa.gov wrote: >> to >> something of interest. > > indeed - still that 'type' bit is quite a cause for confusion. Don't take it too absolutely concretely on a word-by-word basis, though. The "typing" in "duck typing" is a bit like the "bookkeeping" in "creative bookkeeping" :-) David
on 2006-07-26 17:28
On Wed, 26 Jul 2006 dblack@wobblini.net wrote: >> 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 Weirich 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). hmmm. see, i don't think these two ideas are at odds because i agree with you that 'duck typing' can't be implimented via a module (recall that it's this conecpt the started the thread long, long, long ago!). what was bothering me about that is the lack of a concrete term that can actually describe real ruby objects in real ruby code. to say that they a specific object is 'interface polymorphic' is a way of saying what tom was getting at - that the object will respond_to some set of methods (potentially via method_missing) - and is, therefore, an acceptable argument to some method while avoiding the nasty 'is_a' typing issue. also, on further consideration, i'm thinking that duck typing is indeed more of a concept and less a hard and fast set of coding constructs. consider def m yield :foobar end i'd say this is equal in spirit to def m obj obj.foobar end in the first case we simply do not check whether a block was given or, if it was, if it accepts at least one argument. note that this example does not involve an object whose interface may be checked. nonetheless i think it's in the spirit of 'duck typing' to say that this method is 'duck typed' (bad term in know) because we are asserting any preconditions on how it's called and accept that unit-testing and runtime failures are our only tools to track down errors in calling it. contrast that to the second case where an actual object is passed to 'm' and it's required to respond_to? the message 'foobar'. in this case we are also thinking in 'duck terms' but we can also say that 'obj' is required to be 'interface polymorphic' to the set of objects that respond_to 'foobar' called with no arguments. this __is__ something that can be verified (ignoring race conditions inherent in dynamic languages with methods being added) and, therfore, encapsulated in some sort of module. in summary i'm suggesting 'interface polymorphism', or some cute short-hand like PolyFace, as terminology for an implimentation which encapsulates the process of ensuring/checking an object's method signatures/behaviours to determine if that object is allowed to pass a gate or not. regards. -a
on 2006-07-26 17:35
On Thu, 27 Jul 2006 dblack@wobblini.net wrote: >>> whimsical > in "creative bookkeeping" :-) __except__ for the fact that 'type' is easily one of the most semantically and emotionally loaded words for computer scientists - especially those coming from strongly typed languages - so its use naturally (as a search on this list will demonstrate) leads over and over to the people's thinking of 'duck typing' as defining categories meeting 'is_a/can_be' type constraints and as being something that can be written. even though we all know the duck typing that can be named is not the real duck typing. sorry, couldn't resist ;-) -a
on 2006-07-26 18:46
Hi -- On Thu, 27 Jul 2006, ara.t.howard@noaa.gov wrote: >>>> including >> >> Don't take it too absolutely concretely on a word-by-word basis, >> though. The "typing" in "duck typing" is a bit like the "bookkeeping" >> in "creative bookkeeping" :-) > > __except__ for the fact that 'type' is easily one of the most > semantically and emotionally loaded words for computer scientists - > especially those coming from strongly typed languages - so its use I'd say "bookkeeping" is a pretty suggestive and loaded term for accountants and tax people :-) (But read below too.) > naturally (as a search on this list will demonstrate) leads over and > over to the people's thinking of 'duck typing' as defining > categories meeting 'is_a/can_be' type constraints and as being > something that can be written. When it comes to the association between anything with "type" in it and is_a?-style checking, there's a more fundamental (hypoduck?) issue: namely, the tenacity of the assumption that type and class are the same thing. I think that "duck typing" is an attempt to get people away from that assumption -- but the problem is that the duck typing concept, instead, gets reinterpreted to accomodate the assumption. So one hears references to an object's "duck type", when what's really being talked about is simply the object's type (i.e., the object's capabilities and behaviors at a given point in runtime). And as long as one speaks of a "duck type", one implies that plain old "type" refers to something else; and the usual candidate for that is the object's class. David
on 2006-07-26 19:51
On Thu, Jul 27, 2006 at 12:05:06AM +0900, Dumaiu wrote:
> been sure that that one was too fat.
Wild turkeys can fly (badly). Domesticated, not so much. They do tend
to drown in the rain, though.
on 2006-07-26 20:05
dblack@wobblini.net wrote: > And as long as one speaks of a "duck type", one implies that plain old > "type" refers to something else; and the usual candidate for that is > the object's class. If you poke around Lambda the Ultimate for a bit you soon learn that notions of "type" are numerous and quite varied. The terminology gets slippery fast. -- James Britt "Blanket statements are over-rated"
on 2006-07-26 20:18
Jake McArthur wrote: > and-didn't-really-need-a-new-one-but-this-one-is-better-so-let's-make- > everything-twice-as-confusing. I mentioned this term in ch 1 of _The Ruby Way_ (referencing Damian Conway). Hal
on 2006-07-26 20:25
ara.t.howard@noaa.gov wrote: > > even though we all know the duck typing that can be named is not the > real duck > typing. > > sorry, couldn't resist ;-) Haha... well, if you can quote Lao Tzu, I can quote Confucius. I ran across this quote from him last year (no kidding) and it reminded me of duck typing: "If an urn does not have the properties of an urn, can it truly be said to be an urn?" Shades of Plato, actually... Hal
on 2006-07-27 09:50
Dumaiu <Dymaio@gmail.com> wrote:
> No, really, what *is* the sound of a duck typing?
I suppose the very same a human does when typing. However, probably what
it types would be less meaningful.
on 2006-07-27 11:18
On Thu, Jul 27, 2006 at 04:50:04PM +0900, Mc Osten wrote: > Dumaiu <Dymaio@gmail.com> wrote: > > > No, really, what *is* the sound of a duck typing? > > I suppose the very same a human does when typing. However, probably what > it types would be less meaningful. Not to the duck.
on 2006-07-27 12:32
On 7/26/06, Hal Fulton <hal9000@hypermetrics.com> wrote: > year (no kidding) and it reminded me of duck typing: > > "If an urn does not have the properties of an urn, > can it truly be said to be an urn?" To which, of course, the answer is "no, it hasn't urned the right" martin
on 2006-08-03 12:41
On Tue, Jul 25, 2006 at 08:14:59PM +0900, Christian Neukirchen wrote: > > can find some material on that, i think you'll find it interesting. > > While you're at it, have a look at Slate, that also removes single-dispatch. > > > Ron Jeffries > -- > Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org > > CLOS (Common Lisp Object System) has multi-dispatch too. It is more powerful than smalltalk or ruby's message based OOP approach. It is also hard to design in, if you aren't used to it. Given that some people coming from static languages are still wrestling with plain old duck typing, I think it would be overkill for ruby, and hard on a lot of people. It's just not ruby's niche. Jürgen
on 2006-08-03 12:46
On Tue, Jul 25, 2006 at 01:05:11PM +0900, Dumaiu wrote: > runtime errors. For Ruby, where *every* error is runtime, duck typing > is the raw form of its behavior, and should be recognized as quickly as > possible, because it isn't always good. At its utmost, duck typing is > the total absence of validation. You are saying that nothing about > your client's program is worth trying to predict, that 'if it works, it > works,' and if it doesn't, he'll know because it just blew up. No. That's not duck typing, that is shoddy programming. You may have a rescue clause right after your doubtful code, or somewhere else upwards in your call stack. Or it might be guaranteed by application semantics (as opposed to static typeing) that your object can handle the messages sent to it. My take on duck typing: - allows sending messages to objects without *prior* validations. - breaks up dependencies on a strict class hierarchy by allowing to send any message to any object. Neither of them requires that a program may blow up. > Hmm. I see where type-checking came from. As far as Ruby best > practices go, I think 'duck typing' just means using respond_to?() more > than kind_of?() and include?(). If you really wanted to, dumping class > use entirely and turning Ruby into a prototype-based language wouldn't > be too hard: you'd use Object::new() only, define only singleton > methods, and extend objects with clone(); and if you wanted to > delegate, you'd keep an array of references of "parent" objects, > Perl-style. Sometimes it might be better to use #responds_to? early, and many people will still consider this duck typing. It may be less "pure" than handling NoMethodError, but it might be just the right tool depending on your situation. Even #kind_of? can have its merit in certain situations. I wouldn't call code using it to rely on duck typing though, but that's not a bad thing per se. Prototype based languages are tangential to this, and need not be drawn into this discussion here. > Personally, I feel that Ruby needs more, rather than less, type > safety, to balance its natural inclination otherwise and because no > amount of 'duck typing' disaffirms that erroneous behavior is best > caught as soon as possible. But I don't think anyone would advocate a > return to rigid inheritance checking, which realization the deprecation > of type() notably indicates. By your argument, exceptions are bad too, because they catch errors "late". And IMHO exception handling was one of the better points when going from C to C++. Think of duck typing as yet another technique not to litter your code with error checking, but still do it somewhere/sometime. You do handle C++ exceptions too, do you, if not neccessarily right next to throwing them? I repeat: duck typing is not to produce bombing out code, but a new* way to handle dynamic and flexible type validation "late", with the objective to ease development and produce clean code. * actually not. But many people coming from C++ or Java just don't know prior OOP languages. -Jürgen
on 2006-08-03 12:46
On Thu, Aug 03, 2006 at 12:01:50AM +0900, Jürgen Strobel wrote: > "late". And IMHO exception handling was one of the better points when > going from C to C++. Think of duck typing as yet another technique not > to litter your code with error checking, but still do it > somewhere/sometime. You do handle C++ exceptions too, do you, if not > neccessarily right next to throwing them? > > I repeat: duck typing is not to produce bombing out code, but a new* > way to handle dynamic and flexible type validation "late", with the > objective to ease development and produce clean code. I'd say that duck typing is more a means of allowing you to defer rigidity until it's actually beneficial. It has little or nothing to do with delaying validation, and everything to do with avoiding the unfortunate circumstance of having to validate before it's convenient for your code to have something to validate.
on 2006-08-03 12:46
On Wed, Aug 02, 2006 at 11:32:13PM +0900, Jürgen Strobel wrote: > > CLOS (Common Lisp Object System) has multi-dispatch too. > > It is more powerful than smalltalk or ruby's message based OOP > approach. It is also hard to design in, if you aren't used to it. > Given that some people coming from static languages are still > wrestling with plain old duck typing, I think it would be overkill for > ruby, and hard on a lot of people. It's just not ruby's niche. I agree. If we were going to go that route, we'd probably want to give Ruby a functional syntax, at which point we'd just be using Lisp anyway. Let's keep Ruby its own language.
on 2006-08-03 12:48
On 8/2/06, Chad Perrin <perrin@apotheon.com> wrote: > I'd say that duck typing is more a means of allowing you to defer > rigidity until it's actually beneficial. It has little or nothing to do > with delaying validation, and everything to do with avoiding the > unfortunate circumstance of having to validate before it's convenient > for your code to have something to validate. That is one of the most concise statements on the benefits of duck-typing I've ever read. Thanks, Chad! Jacob Fugal
on 2006-08-03 12:50
Duck typing appeals to me specifically because it lets me say that I have a class of People and I can treat them as a list without having to do specific inheritence, et c. Also, on the other-languages discussion, IO is also a prototype-based-OO language. M.T.
on 2006-08-03 13:01
On Thu, Aug 03, 2006 at 01:07:40AM +0900, Matt Todd wrote: > > Also, on the other-languages discussion, IO is also a > prototype-based-OO language. Isn't that language called Io, like the natural satellite, and not IO, like input and output? I ask because I'm not sure -- and I'm too lazy to Google it right now.
on 2006-08-03 13:01
On Thu, Aug 03, 2006 at 12:49:57AM +0900, Jacob Fugal wrote: > On 8/2/06, Chad Perrin <perrin@apotheon.com> wrote: > >I'd say that duck typing is more a means of allowing you to defer > >rigidity until it's actually beneficial. It has little or nothing to do > >with delaying validation, and everything to do with avoiding the > >unfortunate circumstance of having to validate before it's convenient > >for your code to have something to validate. > > That is one of the most concise statements on the benefits of > duck-typing I've ever read. Thanks, Chad! You're welcome -- and thanks for the compliment.
on 2006-08-03 13:10
Jürgen Strobel <strobel@secure.at> writes: > wrestling with plain old duck typing, I think it would be overkill for > ruby, and hard on a lot of people. It's just not ruby's niche. > > Jürgen CLOS has classes, though.
on 2006-08-08 02:10
On Thu, Aug 03, 2006 at 12:39:38AM +0900, Chad Perrin wrote: > > By your argument, exceptions are bad too, because they catch errors > I'd say that duck typing is more a means of allowing you to defer > rigidity until it's actually beneficial. It has little or nothing to do > with delaying validation, and everything to do with avoiding the > unfortunate circumstance of having to validate before it's convenient > for your code to have something to validate. We seem to agree even if you think we don't. "avoiding ... validation before it's convenient" vs. "delayed validation". "defer rigidity" vs. "dynamic and flexible type validation" Now where is the difference apart fom wording? -Jürgen
on 2006-08-08 02:31
On Tue, Aug 08, 2006 at 09:08:40AM +0900, Jürgen Strobel wrote: > > unfortunate circumstance of having to validate before it's convenient > > for your code to have something to validate. > > We seem to agree even if you think we don't. > > "avoiding ... validation before it's convenient" vs. "delayed validation". > > "defer rigidity" vs. "dynamic and flexible type validation" > > Now where is the difference apart fom wording? I don't think we disagree. I just said that's what I'd say -- not that what you'd say is "wrong". Mine seemed a little more descriptive.
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.