[ruby-talk:5758] Re: Dynamic languages, SWOT ?

Dave Thomas wrote:

> ...
> I guess I could see a syntax like
>
>    def fred(a : String, b : File)
>
> which added runtime checks that 'a' and 'b' were compatible with
> Strings and Files respectively, but I'd only support it if the
> qualification were optional. I'd personally use it mostly as a
> documentation tool.
>
> However, remember that this still isn't type checking. In Ruby, unlike
> Java and C++, classes and types are different beasts.
>
> Regards
>
> Dave

I'm not certain that I really agree with you.  I think (feel?) that types and
classes actually are the same kind of thing.  The simpler forms are generally
called types, and the more complex forms are generally called classes, but
the two sometimes smooge over and end up describing the same things.  E.g.,
in Ruby integers are members of some class of integers (which is a small
subset of what number theorist would call an integer).  In Ada, what we call
classes are referred to as tagged types, for good reasons having to do with
history and implemations.
Java makes the distinction that if it is inherited from Object then it is a
class, otherwise it is a type, but that feel like special pleading.  In
Smalltalk everything is whatever they call their kinds of thing, but they are
all the same.  Eiffel seems to uses basically the same distinction as Java:
"If it's built into the compiler, then it's a type, otherwise it's a class".
An argument could be made that types are the pre-defined essences, and
classes are what the user defines, but I don't particularly consider that a
useful position, except when doing rather close to the metal programming.
Somebody's got to do it, but I think that C or Ada would be a better choice
than Ruby, so ...
In this context, I feel that type and class are approximately the same.