David A. Black wrote:
> On Thu, 4 Aug 2005, Eric Mahurin wrote:
> 
>> --- "David A. Black" <dblack / wobblini.net> wrote:
>>
>>> class != type.  Type is at the heart of duck-typing; class
>>> isn't :-)
>>
>>
>>
>> Huh?  Where do you get that?  Duck-typing is about not caring
>> about what the type/class the object is.  Duck-typing in the
> 
> 
> Class is irrelevant, but you'd be well-advised to care about what the
> type is, or you'll find yourself with a lot of NoMethodErrors :-)
> 
>> purest sense is calling the methods of the arguments without
>> regard to what the class of the object is.
> 
> 
> An object's type is the sum of all of its capabilities.  Duck typing
> involves focusing on an object's capabilities -- its type -- and not
> worrying about its class.  You also don't have to "worry" about its
> type (and I agree with those who say that duck typing does not mean
> sticking respond_to? everywhere).  But you are dealing with type --
> dealing with it, in the sense of making assumptions about it, writing
> code governed by those assumptions, etc. -- and not dealing with
> class.
> 
> I like Jim Weirich's characterization of Ruby as "a duck-typed
> language", because it captures the fact that, in a sense, one is
> always doing duck typing in Ruby.  That's also why I always feel
> uneasy with meta-concepts like the "duck type" of an object.  What
> people sometimes call the "duck type" of an object, I call simply the
> type of the object.  Duck typing, in that respect, is a way of
> describing an approach to programming that arises very organically
> from Ruby.
> 
> 
> David
> 

warn "philosophical pootling ahead"

Maybe we need to begin talking about ruby not just as a language with
formal, constructive meanings, but as a "language game" in the sense of
Wittgenstein, with meaning accruing through use.[1]

Obviously, any particular ruby program has a constructive meaning
assigned by the interpreter. But that doesn't capture the way meanings
change as a library is used in different ways over time. I can write a
library that works in one way with all the inputs I've considered, but
because those inputs are "duck typed", there exist future
interpretations of my library, based on inputs with unforseen
implementations, that cannot be explained in terms of the "types" I was
thinking of when I wrote my library.

[1] http://plato.stanford.edu/entries/wittgenstein/#Mea

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407