From: Dave Thomas <Dave@...>
Date: 2000-06-18T06:59:45-05:00
Subject: [ruby-talk:03501] Re: Nominally frozen classes (was Static Typing (was ...))

"Conrad Schneiker" <schneiker@jump.net> writes:

> One reason for wanting some sort of (optional) _nominal_ frozen classes in
> Ruby is so that one could build libraries and such on "solid ground" as it
> were, and thus _warn_ users (-w style, or perhaps raise an exception if
> requested) if the initially presupposed relevant environment was changed
> from under them. Some set of class freezing options may be desirable to
> specify which sorts of class modifications to freeze out and which to
> permit, and whether to propagate freezing to related classes.

But ho could that work in practice? My code uses your code.  One day,
you decide to change the meaning of method xyz, that my code
uses. Freezing doesn't help.

Or take the case of Complex in the standard lib/, which goes messing
around in Bignum, Math, Float, and Numeric. Would we no longer be able 
to use it?

There's a convention that library writers ust follow, a kind of
inverse 'droit de seigneur': no messing with inferior classes. But as
Complex illustrates, one man's messing is another man's reason for
existence. I don't see how you can automate any checks to stop this.

What _might_ be interesting is to consider the possibility of
interfaces (or protocols)--the idea that an object must respond to a
certain set of messages. That would provide a limited but still
meaningful kind of type checking. It also decouples the idea of type
from the implementation using classes, a concept that I like a lot. It 
means that one object may have many types, which is a reflection of
reality. We may even find a way of using the existing mixin mechanism
to implement this.


Dave