David Garamond [mailto:lists / zara.6.isreserved.com]:
> Sean O'Dell wrote:
>> That's just a confidence issue. I don't care if the object coming
>> in is broken. I'm not concerned about catching objects which are
>> implemented improperly; that's actually very rare. If an object
>> had a signature that said "I am a hash-like object" that would be
>> fine for me. Duck typing and checking respond_to? are completely
>> inadequate, and it seems like people argue those points because
>> Ruby offers nothing else and so what are you going to advocate?
>> It's those two or rolling your own interface identification
>> system, which I think is cheesy; that sort of functionality
>> should come from the framework.
> Okay, I'm trying to sum up this thread as well as test whether my
> understanding of this whole typing issue in Ruby is more or 
> less correct.

> 1. Ruby _has_ types. It's called classes. In fact, all OO
>    languages which have a class concept (as opposed to some
>    classless OO languages like Self, I think) implement types
>    through classes. All object belong to a certain class. That
>    class is the object's type.

Actually, Ruby has both types and classes. Many developers confuse
types and classes because in C++ they are one and the same; in Java
they are slightly different, but not noticeably so (with the
introduction of interfaces).

An object of class Array is both an Array and an Enumerable; it also
belongs to the nebulous class of "objects-that-respond-to-#[]". In a
current project, I am dealing with "objects-that-respond-to-#<<".
This allows me to buffer output in a string, an array, or simply go
to an IO object.

> 2. However, Ruby does _not_ do type checking for you. This means,
>    method declaration is not like this[...]

Again, a clarificatio: Ruby does not restrict method signatures.
This is a Good Thing.

> 3. Ruby also does not tag a variable with type. This means, you
>    don't declare variable's type like this[...]

Correct. Ruby variables are untyped; objects, however, are typed. To
be quite explicit: Ruby variables don't have types at all; the
objects that they reference do.

> #2 and #3 are perhaps what people miss when they move from
> C++/Java to Python/Ruby. I don't know whether Ruby will ever have
> #2 and #3.

I hope not, personally, as it would reduce the flexibility of the
language. Slides from last year's RubyConf, however, suggest that #2
may happen to some degree. I prefer a descriptive rather than
restrictive interface for this stuff, though.

> 4. Static type checking (or static typing?) is #2 and #3, done at
>    compile time. This is what C++ and Java do. Ruby, of course,
>    does not have type checking, much less static type checking.

No. Ruby does not have "class-checking" or "interface-checking"
built into the language. It does have type checking in that if an
object does not respond to a method -- or does not respond properly
-- it will cause an exception to be raised (NoMethodError,
ArgumentError).

[snip]

Points 5, 6, and 7 share other (similar) flaws. Note that Ruby's
modules *are* interfaces.

-austin
--
austin ziegler * austin.ziegler / evault.com