Re: Types (was Re: Ruby lecture slides (was Strong advantages over Python))

On Monday, March 24, 2003, at 09:06 AM, [e-mail] wrote:

> [snip]
>>> Take this example:
>>>
>>>    class Fred
>>>      def shout
>>>        puts "wilma"
>>>      end
>>>    end
>>>
>>>    f = Fred.new
>>>
>>>    o = Object.new
>>>    def o.shout
>>>      puts "wilma"
>>>    end
>>>
> 'f' and 'o' have different classes (Fred and Object respectively) but
>>> they have indistinguishable types (for all intents and purposes). In
>> [snip]
> My characterization of those types, if I had to provide one, would be
> something like: respondent to "shout".  Of course that kind of
> circular description doesn't scale well in the face of a more
> extensive set of methods, which I think is one reason why the idea of
> type is inadequate to the task of telling us much about Ruby objects.
>
> [snip]

First, this example leads me to an "Aha!" moment, for which I thank 
David Thomas. Classes can represent any type and need not have the same 
name, even if the type is identical. Also, the concept of type is less 
important where one is interested in side effects. Also, Ruby permits 
the programmer to not be concerned, if they so choose, about the domain 
definition aspects of type, which can be helpful.

I don't think it is necessary to name the types of 'f' and 'o' but they 
can be described by their behavior, which is identical. To the extent 
two different classes have different methods, of any number, they are 
different types, which types may, but need not be, named if necessary 
or convenient.