Ah, the joys of discussing typing in Ruby... at least neither
of us is on the side of wanting static types in Ruby.

--- "David A. Black" <dblack / wobblini.net> wrote:
> On Thu, 18 Aug 2005, Eric Mahurin wrote:
> >>> Take a look at the original definition of duck-typing
> given
> >> by
> >>> Dave Thomas.  Here is the example he gave:
> >>>
> >>> | When I write
> >>> |
> >>> |     fred << "dog"
> >>> |
> >>> | in Ruby, I don't care whether fred is a String, a File,
> >> or an
> >>>
> >>> | Array
> >>>
> >>> In this context, the "duck type" of fred is something
> that
> >>> reponds to <<(aString).
> >>>
> >>> By your definition of "type" being "the sum of all of its
> >>> capabilities", you'd have to pick what "type" fred is -
> >>> String-like, File-like, or Array-like.
> >>
> >> On the contrary: I *don't* have to pick or describe or
> find
> >> synonyms for what it is.  That's the point: the type is
> what's
> >> there.  I don't even have to name it.
> >
> > From what you said above, I don't see any debate over how I
> > defined "duck type" (other than the name).  I only see you
> > clarifying what you meant by "type".  I still don't see a
> > concrete definition of yours, but it sounds like you might
> mean
> > the same as what I said for "duck type".  But, when you say
> > "type" is "the sum of all of its capabilities" and "an
> > object's type can change and evolve during runtime" this
> says
> > to me your "type" is associated with the object itself and
> not
> > how the object is used.  All that really matters regarding
> > "type" in my opinion is how an object is used.  What a
> > particular object's entire capabilities and the fact that
> they
> > can change over time is orthongonal.
> 
> It sounds like you think I mean you should send all possible
> messages
> to an object simultaneously, or something bizarre like that.

No, I'm only talking about how to describe a particular type
(most likely in documentation).  I think you and I both agree
that in normal circumstances, one's ruby code should not do any
checking of the type - however you define it (kind_of?,
responds_to?, etc).  Otherwise you'd be "caring" about the type
which goes against duck-typing.

> Obviously any given use of an object does not recapitulate or
> encapsulate its entire type, if "type" is defined as the
> object's
> capabilities.

And that is why I think this definition of "type" is not very
useful.  The definition I gave for duck-type is quite useful in
the context of duck-typing - for documenting arguments of
methods.

...

> > I'm not sure why you don't like the term "duck type".  It
> is
> > directly associated with the term "duck typing" and is
> quite
> > clear in that context.  I don't understand the need to talk
> > about/document an abstract "type" beyond the context of
> "duck
> > typing".  Can you think of anything else?
> 
> I don't like the term "duck type" partly because I consider
> "type" to
> be adequate (since type in Ruby is already a matter of
> dynamic
> message-recognition capabilities, rather than class
> membership), and
> partly because I think the word "duck" sometimes gets used so
> much and
> spread so thin, as a kind of general code-word for anything
> connected
> with dynamic typing, that the original sense of "duck typing"
> gets
> diluted and obscured, which I think is too bad.

I'm not diluting duck-typing at all.  In static typing
languages, you associate a specific static type with an
argument.  This tells the caller what kinds of oubjects it can
use there.  When doing duck-typing within a method, you
describe the duck-type of each argument in the dcumentation. 
There is no  direct code to describe them, but the caller needs
to know at least from documentation.

> >> I personally wouldn't say "anything IO-like" (nor
> "O-like", though
> >> that might be closer :-) but rather: anything that
> responds to
> >> "write".  That's *all* that matters.  "IO-like" is a
> secondary
> >> concept, built on top of that.  Let's say someone said:
> "no, it's
> >> not IO-like; I reject that." That person could still send
> "write"
> >> to fred, as much as you can.
> >
> > My point was that if you document your method to take an
> > IO-like object (which I thought was your way - sum of the
> > capabilities of an object), you have the freedom to use any
> of
> > the IO methods.
> 
> I think I may see the problem here: perhaps you think I meant
> "summary
> of the capabilities of an object"?  I can't think how else
> these
> notions like "IO-like object" have crept into the discussion.
>  You
> seem to think I meant I want to slap specific, sort of
> pseudo-type
> labels on objects (IO-like, String-like, etc.), when what
> I've been
> trying to say is more or less the opposite of that -- namely,
> that the
> "type" of a Ruby object really cannot be labeled or
> summarized in this
> kind of way, because it is only defined by what it actually
> is at a
> given moment.
> 
> In fact, the tautology of type renders it close to useless as
> a
> concept in Ruby; but in a pleasant way, I find.

So you do see this definition of type being useless :)  I think
we are on the same page - mostly.

> > If initially the method is implemented using
> > <<, it may work with anything that has the << method now,
> but
> > you run the risk of something breaking if the
> implementation
> > changes to use different or additional methods.  If you
> > document a method like this, you give the method
> implementation
> > freedom to use a wide range of methods, but limit the
> caller to
> > objects that implement that entire interface.
> 
> Why wouldn't you just say: "the argument to this method has
> to respond
> to <<" ?

Yes, that would be the best (duck-typing) way to do it.  I was
just giving a counter-argument as to why you might "require" an
argument to conform to an entire "interface" (or your "useless"
definition of "type") - method implementation freedom.  I think
the method caller freedom is more important.

> > Of course that is not the duck-typing or ruby way.  The
> > duck-typing way is to document what capabilities you
> want/need
> > from an argument and that's it.  This gives more freedom to
> the
> > caller and less to the method implementation.
> 
> I would just call it "documenting a method" :-)

And I'd call it describing the duck-type of an argument just
like one would declare the static-type of an argument in a
statically typed language.   If a method doesn't do duck-typing
and instead checks for a class, you'd give that class in the
doc instead of describing a duck-type.  Or if the method did
different things based on the objects capabilities/class you'd
be describing something else - not a single duck-type. 
Describing a duck-type goes with duck-typing.

> But I'm not
> the duck
> police; you can use it any way you see fit.  Certainly
> documenting the
> capabilities you need from an argument sounds like a good way
> to go
> about documentation.  Objects whose type comports with the
> stated
> needs can then be used as arguments to that method.
> 
> 
> David
> 
> -- 
> David A. Black
> dblack / wobblini.net
> 
> 



		
__________________________________ 
Yahoo! Mail for Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail