From: Charles Hixson <charleshixsn@...>
Date: 2000-10-22T13:10:02+09:00
Subject: [ruby-talk:5748] Re: Dynamic languages, SWOT ?

Dave Thomas wrote:

> 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)

Only one answer here, mainly questions:
Actually, I believe that you can implement a run-time constraint.  It just isn't
obvious what kind of standardized action should be taken.   So it's not clear how
the language could reasonably respond.  Also, it's not clear how one should
declare a parameter to be of a type.  Inheritance could be used, but isn't really
appropriate.  What is really wanted is something on the order of:
The paramer must respond to the following messages: ...
and must not throw any more than the following exceptions: ...
And then what should you do if it is in violation?  Currently an error is raised
(forget which one).  What is a more elegant way to handle this?  I don't think
that it could be reasonably detected until during execution, but I could be
wrong, so, if you could detect it, then what would you want it to do?  Abort the
program?  Throw and exception?  Loop?  Wait forever?
Throwing an exception is the best one that I've been able to think of.  It would
be nice if it could be detected at an earlier stage, but then what if the branch
of the program to be followed never executed the statement in violation?
Programs often have branches that are only executed when the inputs are of a
certain specific kind.

> ...

> 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).

I think that Ruby already has such a list, but I could be confusing it with
Python (and don't know how to look this up quickly).  This isn't a formalized
thing created for users.  It's just that the compiler uses a list to keep track
of things, and that isn't hidden away.  (If you've done that "quick hack", then
I'm sure you know what I'm referring to.)
The problem is,  if you were to design a user interface to this list, what should
the API look like?  Remeber that included files can change the structure of the
class (defining new methods), and that individual members of a class can have
methods added to them (I still struggle when thinking of this as a Singleton, but
I suppose that it is).
So it looks like this list doesn't only exist for the class, but also for the
members of the class.  And, at least for the members, and probably for the entire
class, this list can be changed dynamically .  (When WILL that book show up! ...
I've already ordered it, but it sure would be nice to have a reference right
now.)

>
>
> 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?

The fundamental difference is that at programming time Java required knowledge
that the found element would necessarily be castable to type Employee, rather
than, say, Consultant, or Owner.  Now it you had been asking about C ...

>
>
> Regards
>
> Dave

Java is an interesting case.  It seems to carry enough information around that it
SHOULD be able to tell what the type of an object is.  But it can't.  It depends
on type declarations embedded in the program which must be program time
constants.  (Program time comes prior to compile time).  In C it come prior to
pre-processor time.)  This wouldn't be quite as wierd as it is if it weren't for
ClassLoader.  ClassLoader can take a file of compiled code, and extract the types
of the objects that it contains.  So the information is in there.  My guess it
that this constraint is a part of Java's security model, but I don't really
know.  Anyway, making type declarations programming time constants, but not
taking advantage of the optimizations that this makes possible in Strongly
typed-Statically linked languages, is one of the design decisions that were made
in creating Java.  This is the kind of choice that makes me uncertain of just
where in language space I should position it.