From: "David A. Black" <dblack@...>
Date: 2005-08-04T07:47:22+09:00
Subject: Re: [RCR] array or with non-array

Hi --

On Thu, 4 Aug 2005, Eric Mahurin wrote:

> Whatever your definition of type is, a method should not care
> (i.e. check) about the types of its arguments.  It should just
> assume that the arguments have the capabilities that it wants.
> That is is core of duck-typing, is it not?

I guess it usually involves method arguments, though only indirectly
-- meaning, it's about how objects are treated, and what assumptions
are made about them, whether or not they arrived on the scene as
method arguments (though I guess that's the usual scenario).

> I also think your definition of type (or duck-type) is too
> restrictive.  Instead of "An object's type is the sum of all of
> its capabilities", it should be "An argument's type is the sum
> of its capabilities that the method uses or documents that it
> may use".  Every method argument has its own duck-type.

My definition of "type" isn't restricted to method arguments, so your
definition doesn't work as a drop-in replacement :-)

I don't find the concept of a "duck-type" very useful.  *Type* in
Ruby, without the duck, already reflects something dynamic, flexible,
unrestricted by class/module ancestry, and so on.  Duck typing is a
way of leveraging type, in this sense.

> But, back to the original thing that spawned this discussion -
> the String#[] method.  I claim that this violates the spirit of
> duck-typing all over the place because of the class (or type)

(definitely class, in this case)

> checking done to accomplish multiple functions.  Do you claim
> it is duck-typed?  If so, show me how you could get the
> multiple functions that it has and still be duck-typed.
>
> My point is that when coding ruby, we are encouraged to use
> duck-typing, but the ruby library itself does not.  Seems kind
> of hypocritical.

You're turning it into a game of "Simon Says" -- "Uh oh, you branched
on class membership: you're out!" :-)  I think it's a little more
subtle than that.  As I said before, I tend to be accepting of
hard-coded class-based things when they're in the core, since it
provides such a flexible and powerful programming environment and
there's no mandate to base one's Ruby style on the class-name checks
in the C source.


David

-- 
David A. Black
dblack@wobblini.net