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


On Nov 21, 2003, at 1:33 PM, Sean O'Dell wrote:

> [snip]

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

I think Ruby has (abstract) undeclared mutable interfaces now. I think 
that the programmer(s) should have the option of when they want to lock 
an interface on a case-by-case basis, rather than lock everything by 
bringing in the interface infrastructure.

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

I'm thinking that the whole thing should exist, if at all, completely 
separate from Ruby, at least until it has been "seasoned" with 
extensive and widespread use.

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

I think just a different metaphor for the "interface" to the interface 
descriptions. I think Ara Howard's thoughts on doing it inline are 
better than my table suggestion.

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

Rite. :-)

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

I think there is a large potential cost (and benefit) on the human 
interface side, the full extent of which is not knowable in advance of 
getting some working implementations. I think doing it in Ruby and 
keeping class and method modeling separate from interface declaration 
lower the cost of trying it.

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

Unfortunately, I asked the question because I know only enough about 
Objective C to know that it is compiled and dynamically typed and has 
optional static type declarations.

> [snip]


Regards,

Mark