On Friday 21 November 2003 07:23 am, Mark Wilson wrote:
> My own views on interface crystallization:
>
> 1. It should not be done in-line, but rather through a separate express
> creation of an interface table. [Note: one of the nice things about the
> way Ruby (and other languages) does things is the inline creation of
> dispatch on type tables for generic operators through the use of
> classes in an object system. It would be bad to complicate this and
> other elements of Ruby's human interface by also putting interface
> "contracts" inline with Ruby's current (usually very comprehensible)
> class declaration system.]

Agreed.  But also, one of the advantages to having the interfaces separate is 
they won't be cluttered with code, which means you can browse an interface to 
determine what it does in one compact location.  Much different from browsing 
classes.

> 2. The table would include fields specifying whether the interface is
> mutable or immutable, the number of arguments and "types" of arguments
> a method takes, exceptions to raise if the particular interface element
> fails, and so on.

Just for example, why would someone need a mutable interface?

> 3. A skeleton table could be generated from existing code, with
> suitable default values (such as mutable interface, argument "type" set
> to Object, etc. The developer would choose where to crystallize an
> interface element and forego additional possible dynamism.

You mean, sort of a class extractor that can generate an interface template 
that they can then edit to suit their needs?  If so, that's something that 
could be a third-party utility.

> 4. The table could be queried to produce detailed documentation
> information and/or included at runtime as a constraint on execution.

Is the table different from the interface description I describe in the wiki?  
The proposal now already plans to constrain method calls based on the 
interface description.

> 5. In the future, one could perhaps also use the table to guide a Ruby
> compiler as to when a form of "static typing" can be used to optimize a
> particular program (according to the instructions of the developer).

Perhaps ... but I think going this far might too far off Ruby's path.

> I do not, however, think the proposal is necessarily a good idea. It
> does seem very costly, and the magnitude of the benefit is not clear to
> me. A way to make it lower-cost would be good, because then it would be
> easier to try.

It's pretty cheap in terms of run-time overhead.  It really does only the bare 
minimum I can imagine any form of type checking doing.  It only tests for an 
"interface compliance" flag at run-time; that's little more than a test for 
true/false.  How much cheaper can it be?

> Some questions:
> Have the main proponents (and critics) looked at how Objective C
> handles this and similar issues?

No, but I'm open to ideas.  =)

> How would this handle methods that take blocks?

Interesting problem, but one that definitely can be worked out.  It doesn't 
appear to be circular, but I'm not aware of all the issues regarding them, so 
I think it's workable.

> How can Ruby better document the kind of block code that would be
> useful with respect to a particular method?

I'm not sure what this question is.  I speak perfect English, too.  =)

> How would this, and related ideas, work in a distributed environment,
> where one might wish to differentiate site-specific capabilities?

Don't laugh at me, but: what?

	Sean O'Dell