From: Simon Strandgaard <0bz63fz3m1qt3001@...>
Date: 2003-06-25T23:02:41+09:00
Subject: Re: protect parents from children

On Wed, 25 Jun 2003 14:22:56 +0000, Martin DeMello wrote:

> Simon Strandgaard <0bz63fz3m1qt3001@sneakemail.com> wrote:

>> BTW: Perhaps it could be nice if you could say:
>> 
>> class A
>>  def initialize
>>    @value = [1, 2, 3]
>>  end
>>  subclass_freeze :value      # maybe nice to have ?
>> end
> 
> This *is* probably hackable, with some judicious delving into Module and
> hooks. But you can only freeze an object, not a variable, so it would
> prevent @value << [foo] in a subclass, but not @value = bar

:-)
 
> Is it a variable whose value can be mutated in any methods you 
> write inside class A, but which client programmers writing classes that
> inherit from A can only treat as a constant? 

Yes. Any method within A is able to read+write (mutable).

Subclasses of A is only able to read (imutable). 
If subclasses attempt to write they die.


> How about if they call a method from A which changes the value 
> of @value? 

Subclasses should be allowed to call a superclass-method, which does make
changes.    


> What if they override @initialize and don't call super - how does 
> the value get set, then? 

I don't know which kind of behavier would be appropriate here?


> And don't forget they can simply reopen A and add a method of their own,
> then call it from B.

I consider 'reopen'ing as a kind of subclassing. if subclass then its
readonly mode :-)

--
Simon Strandgaard