"stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types)

ruby-talk
1

Simon:

class Duck promises IBird
…
end

if someobj.has_promised(IBird)
…
end

promises are made to be broken

Best Regards,
t0

2

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.

eg (wild speculation here)

ruby foo.rb
==> just as now, no typechecking of any sort. No performance hit.
On error, the metadata about method parameters may be used to
provide improved error messages. There will be minor memory usage
increase due to the metadata stored - should be very small though.

ruby --type-warn foo.rb
==> generates warnings on possible violations, typically used during
debugging or uat phases. A performance hit of 10% or so expected and
acceptable in this situation

and maybe…

ruby --type-check foo.rb
==> strict type-checking, with errors reported on typecheck failures.
Available to those who want it, and are willing to wear the
performance hit. Some libraries may not work in this mode.

···

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

–

T. Onoma, do you actually have a concrete proposal related to type info?

The duck_signature method you mention is a syntax for consulting type
info, assuming it has somehow been gathered. I haven’t seen an email by
you that suggests how that type info might have been acquired in the
first place, or how it is stored…

Cheers,

Simon

3

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

Sean O'Dell
···

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.