From: Sean O'Dell <sean@...>
Date: 2003-11-20T14:33:24+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types)

On Wednesday 19 November 2003 08:38 pm, Simon Kitching wrote:
> On Thu, 2003-11-20 at 16:52, T. Onoma wrote:
> > Simon:
> > > class Duck promises IBird
> > >  ...
> > > end
> > >
> > > if someobj.has_promised(IBird)
> > >    ..
> > > end
> >
> > promises are made to be broken
>
> Yes, that's why I chose the word!
>
> As Sean O'Dell has said, the point is to communicate intentions, not to
> absolutely forbid people from doing things.
>
> So I see it as acceptable for someone to write a class that "promises"
> to behave like a bird, but doesn't really (or extends an existing
> class). The author has made the decision. But they were immediately
> *aware* that the called method expected a bird, and presumably very
> carefully investigated the implications of breaking the expected
> behaviour.
>
> In Ruby you certainly should be able to bypass anything if you wish -
> it's the language philosophy and wouldn't be Ruby without it.
>
> Maybe we should be using the term "type hinting" rather than "type
> checking"? That's certainly what I'm talking about, and pretty sure it
> is what Sean O'Dell is talking about too. Hints to the programmer
> reading the code, hints to code doing "reflection" type operations,
> hints available to the runtime environment when generating error
> messages. But nothing compulsory, nothing "forcibly checked" - well,
> unless the user *wants* it checked.

This is precisely what I am talking about.  On the nose.

	Sean O'Dell