From: dblack@...
Date: 2006-05-16T05:51:36+09:00
Subject: Re: begining programmer questions

Hi --

On Mon, 15 May 2006, Francis Cianfrocca wrote:

> I have to admit I don't understand the distinction you're making between
> "class" and type.

Basically, class is the thing that the object is an instance of.  Type
is the sum of the object's behaviors -- which may or may not be
exactly the same as the behaviors it started out with.

> To level-set: I care about this discussion primarily
> because plenty of people (but no one on this thread, of course) criticize
> Ruby as being less strongly-typed than C++ or Java, whereas the truth is
> that Ruby is _dynamically_ typed rather than _weakly_ typed. In Ruby, an
> object never changes its type (although delegation and the ability to add
> methods to a single object instance also may make it seem like it does).

It never changes its *class*, but it can change its type.

> More to the point, Ruby will never implicitly perform operations on an
> object that are not part of its type, as a result of inferences about some
> particular statement of code. This Ruby code will generate an error:
> "abc" + 5

Yes, but this won't:

irb(main):004:0> a = "abc"
=> "abc"
irb(main):005:0> def a.+(other); self << other.to_s; end
=> nil
irb(main):006:0> a + 3
=> "abc3"

The thing about type in Ruby is that there are no words for different
types.  There's no need for them; the fact that a defines + the way it
does is all you'd need to know.  There's no need for a word that
means, "the type of objects that start out as strings but redefine +
so that it performs an automatic to_s....."  And since the type
spectrum is infinite, there's no way to have words for all of them.

> I've noticed that younger programmers seem to have much less conceptual
> trouble with "duck typing" and dynamic languages than older people like me.
> I wonder if it's because for a while, CS programs taught people with
> functional languages like Scheme, where the distinction between objects and
> variable-bindings is explicit and clear. (Nowadays of course, all the
> younger people coming out of university seem to have learned nothing but
> Java...)

I'd be at least mildly surprised if you're older than I am :-)  But in
any case, it comes down to this: There are two things going on with
Ruby objects.  One is their class.  The other is the fact that they
are dynamic; their behaviors can change, and even two objects that
report themselves to be of the same class can have different
behaviors.

It's conventional to refer to the first of these things as class, and
the second as type.  The disadvantage of referring to the first one as
both class *and* type is that then we need a new word to refer to the
second one, when in fact "type" is really the best word.

(See the Pickaxe (2nd edition) for a lengthy and enlightening
discussion of the difference between class and type in Ruby.)


David

-- 
David A. Black (dblack@wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
   > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
   > http://www.manning.com/black