[#3109] Is divmod dangerous? — Dave Thomas <Dave@...>

14 messages 2000/06/06

[#3149] Retrieving the hostname and port in net/http — Roland Jesse <jesse@...>

Hi,

12 messages 2000/06/07

[#3222] Ruby coding standard? — Robert Feldt <feldt@...>

16 messages 2000/06/09

[#3277] Re: BUG or something? — Aleksi Niemel<aleksi.niemela@...>

> |I am new to Ruby and this brings up a question I have had

17 messages 2000/06/12
[#3281] Re: BUG or something? — Dave Thomas <Dave@...> 2000/06/12

Aleksi Niemel<aleksi.niemela@cinnober.com> writes:

[#3296] RE: about documentation — Aleksi Niemel<aleksi.niemela@...>

> I want to contribute to the ruby project in my spare time.

15 messages 2000/06/12

[#3407] Waffling between Python and Ruby — "Warren Postma" <embed@...>

I was looking at the Ruby editor/IDE for windows and was disappointed with

19 messages 2000/06/14

[#3410] Exercice: Translate into Ruby :-) — Jilani Khaldi <jilanik@...>

Hi All,

17 messages 2000/06/14

[#3415] Re: Waffling between Python and Ruby — Andrew Hunt <andy@...>

>Static typing..., hmm,...

11 messages 2000/06/14

[#3453] Re: Static Typing( Was: Waffling between Python and Ruby) — Andrew Hunt <andy@...>

32 messages 2000/06/16

[#3516] Deep copy? — Hugh Sasse Staff Elec Eng <hgs@...>

Given that I cannot overload =, how should I go about ensuring a deep

20 messages 2000/06/19

[#3694] Why it's quiet — hal9000@...

We are all busy learning the new language

26 messages 2000/06/29
[#3703] Re: Why it's quiet — "NAKAMURA, Hiroshi" <nahi@...> 2000/06/30

Hi,

[#3705] Re: Why it's quiet — matz@... (Yukihiro Matsumoto) 2000/06/30

Hi,

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

From: Dave Thomas <Dave@...>
Date: 2000-06-18 11:59:45 UTC
List: ruby-talk #3501
"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

In This Thread