[ruby-talk:03499] Re: Nominally frozen classes (was Static Typing (was ...))

Hi,

"Frank Mitchell" writes,

> Patrick Schoenbach wrote in message ...
> >On Sat, 17 Jun 2000 09:32:08 GMT,
> >Thaddeus L. Olczyk <[e-mail]> wrote:
> >
> >>On Thu, 15 Jun 2000 22:11:34 -0400, Andrew Hunt <[e-mail]>
> >>wrote:
> >>>I disagree strongly.  While Meyer is an advocate of static typing, I
> >>>see no reason that DBC cannot be effective in a dynamically typed
> >>>environment -- in fact, it seems to me that DBC could be even *more*
> >>>useful in a dynamic environment than in a static one.
> >
> >I agree with Andy here. IMHO DBC and typing are two different things. We
> >Eiffelists believe that static typing is better suited to create robust
> >and correct systems. This is heavily argued thought, and we should not
> >start another "static vs dynamic typing" war.
>
>
> Agreed.  Dynamic typing is very useful for rapid development, and for
> high-level "glue" code the rigor of strong typing hinders as much as (or
> more than) helps.
>
> >But DBC is not directly related to the typing issue. Even in Eiffel,
> >assertion checking is done completely at *run time*. So, I see no
> >problems either to implement DBC in a dynamic environment.
>
>
> I think it's more closely related than it seems at first blush.  See my
> previous post.
>
> Granted, your contracts can include a union of types, or "types" defined
by
> a set of methods and contracts instead of by name ... but to exploit the
> power of DBC you need some sort of type system and type checking.

Well, I am not a DBC lawyer, however it seems to me that people have
somewhat different reasons for being interested in contracts. One reason is
to guarantee _in_advance_ (nominally at compile time or startup time) that
contracts _can_ be carried out subject to given constraints. A second reason
is to guarantee that contracts will be enforced during execution (in the
sense of preventing contracts from being violated), but not necessarily
guarantying that (the _primary_ objectives of) all contracts will be
fulfilled. It is the first case where static typing seems to be the most
appropriate solution. In this context, conventional static typing can be
regarded as simplistic data compatibility and data integrity contracting.

Of course Ruby already has a form of static typing in the form of frozen
objects. (However IIRC, many months ago someone mentioned that it was
possible to somehow change constants. If so, I think the ability to change
things like our good friend PI (3.141592653589793238....) out from under
people is carrying flexibility a little too far.)

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.

Conrad