From: "David A. Black" <dblack@...>
Date: 2005-04-29T19:08:45+09:00
Subject: Re: ruby static typing

Hi --

On Fri, 29 Apr 2005, Lyndon Samson wrote:

> On 4/29/05, David A. Black <dblack@wobblini.net> wrote:
>>
>> The link also has other comments, as well as links to other
>> discussions (though there have been many more here on ruby-talk since
>> then).
>>
>
> It would be nice to have a statically typed Interface of some sort
> though, just to have  something publishable, enforceable and easy for
> tools to analyse.

I question whether a tool can analyze the capabilities of an object
whose capabilities are subject to runtime-only changes.  To the extent
that the tool checks for class/module membership and ancestry (as
opposed to type), you're only getting the illusion of "type" and
therefore the illusion of type safety.  That kind of check also
discourages duck typing (of which it is essentially the opposite) and
generally operates to constrain Ruby programs to a model and set of
programming habits for which the language does not, by design, provide
very much support.

As Matz once put it (in response to another RCR about static typing):

   Ruby IS dynamic language. What you propose is to introduce static
   typing into Ruby which violates the whole idea of Ruby Way. Please,
   understand that class declaration has nothing to do with interfaces
   or with idea of types. Class is just a convenient place to place your
   your method declarations. An object can be changed dramatically during
   its lifetime and the type of the object is determined only by methods
   it responds to in any particular period of time.

One can of course ask an object what it responds to, before sending it
a message.  That's a better fit, as a Ruby type-checking technique,
than class/module name-checking.  It is not the same as duck typing,
though it's more in the same family of techniques.  As I said in
another recent post, I personally tend to view respond_to? a kind of
"weak" duck typing: duck typing, in the sense that it deals directly
with the object's type and not with its class/module ancestry; "weak",
in the sense that it splits apart the checking for a behavior and the
requesting that behavior.

Quick Q&A, so that we don't have to go through them one by one :-)

   Q: Isn't changing an object's behavior dynamically bad practice?
   A: No.  That's what #extend is for, and that's why adding a method
      to an object is as easy as:  "def obj.meth; end"  The idea that
      this is bad is based on considerations extrinsic to Ruby.

   Q: Do that many objects *really* get changed so that their classes
      don't match their type any more?
   A: Some -- and it's always possible, and it's a technique people
      should be free to explore (since it's the basis of the design
      of Ruby).

   Q: Isn't Matz talking about adding some kind of
      type-checking/filtering functionality to Ruby 2.0?
   A: Yes.  As far as I know it's still at the very broad conceptual
      stage.  Presumably it won't be a classname checking system :-)


David

-- 
David A. Black
dblack@wobblini.net