From: Mark Wilson <mwilson13@...>
Date: 2003-11-22T00:23:53+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

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

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.

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.

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

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

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.

Some questions:
Have the main proponents (and critics) looked at how Objective C 
handles this and similar issues?
Could this, or something similar, be done within Ruby?
How would this handle methods that take blocks?
How can Ruby better document the kind of block code that would be 
useful with respect to a particular method?
How would this, and related ideas, work in a distributed environment, 
where one might wish to differentiate site-specific capabilities?

Regards,

Mark