Charles Hixson <charleshixsn / earthlink.net> writes:

> > This is the area I'm thinking about where the typing is not so strong
> > as would ease error detection.  OK, types can be dynamic, but for
> > parameters it only make sense for them to be in a subset of the
> > class heirarchy.   There is no way to express this constraint in Ruby
> 
> This is a run time check in a dynamically bound language.  I'm pretty sure
> that Ruby does have ways to catch this, though they don't seem, to me, to be
> quite as ?elegant?, ?standardized? as those that Smalltalk uses.  Much more
> similar to the techniques of Python.

Well, I'm not sure what Ruby could do here, apart from implementing
protocols. You can't constrain a parameter to be an object of a
particular class: it's the methods that the object supports that is
relevant, not the class itself (as I know everyone knows--I'm just
reemphasizing the point)

So,

   def append(to, what)
     to << what
   end

works equally well when passed a File, and Array, or a String as it's
first parameter.

Objective C had the concept of protocols, which are similar to Java's
interfaces, which specified what messages an object supports.  This
_could_ be added to Ruby (I have a quick hack that implements them in
Ruby itself).

However, let me ask a question: how often do you get bitten by this in 
reality? And, having been bitten, how long does it take to fix?

Personally, I find that I pass in a wrong object about once in a blue
moon, and it becomes apparent that I goofed pretty quickly.

Now ask yourself a different question. Right now, legions of Java
programmers are using

   Employee emp = (Employee)staff.nextElement();

Fundamentally, how is this different from using Ruby's type system?


Regards

Dave