From: Simon Kitching <simon@...>
Date: 2003-11-20T14:27:29+09:00
Subject: Re: "stereotyping" thread

On Thu, 2003-11-20 at 18:05, Wesley J Landaker wrote:
> Why not just use empty modules for all this type-checking? This isn't 
> very useful to me personally, but it seems to do everything that has 
> been mentioned in this whole "stereotyping" thread (i.e. emits warnings 
> if the passed in types haven't been manually tagged by a programmer as 
> implementing a particular interface):

ROFL!!!

It's nice to see minds thinking alike :-) My suggestion of exactly that
sort of kicked off this thread! [Well, Sean O'Dell clearly had ideas
that were much more thought out than mine].

There are some flaws to it, though.

The question "what interfaces does object Foo implement" can be answered
by the "include module" approach, and that is a step forward - but just
not big enough to go all the way.

The fact that a method expects something obeying SomeInterface isn't in
the method declaration, so it isn't easy for someone browsing the code
to see. Nor is it easy to put into the rdoc-generated documentation. Nor
can it be queried at runtime, ie "what interfaces are the parameters to
this method expected to implement?".


And the typing is enforced "hard". Austin has made a good case that Ruby
type-checking should always be bypassable. Well, he actually suggests we
are mad for wanting it at all, but I'll grant him this part of the
argument at least.

I suggested a command-line option to the ruby interpreter (or similar
mechanism) control how "strictly" checks are done, with the default
being "not at all". This cannot be done directly with the code you
suggested. Yes some method like
  assert_implements(foo, SomeInterface)
could go off and check the "strictness" level to determine whether to
raise an exception or not, but that would have a significant performance
hit even when typechecking is disabled.

Some people also felt that "typing" should not be related to "class
inheritance". I'm not so sure about that.

So here I am rebutting my own suggestion proposed independently by
someone else :-). I'm still hoping for someone to make a suggestion for
a type info mechanism, though, by whatever approach.


Cheers,

Simon