Hi Robert,

Robert Dober schrieb:

>> Perhaps it would help implementing this idea,
>> if the << method would be made special
>> and be the only accepted modifying method
>> in the "growing" state.
>
> Hmm maybe that has something to do with your "permanent" methods, of
> which I fail to grasp the idea right now.

No, nothing to do with that.
The idea was meant as a quick solution:
      If an object is in "crystallizing" or "semi_frozen" state,
      then react to every method call, as if it were frozen, except to 
the << method.

I had meant this just as an easy default strategy for new classes,
I still would like to be able to use the normal methods for built-in 
objects.
(In particular, I would want to write
  hash[key] = value
instead of a newly introduced
  hash << [key,value]
)


> Assuming that << is the only writing method to a semi-frozen object we
> would need to freeze the methods on the object, like pulling them into
> the object and disallow method lookup. 

Yes, for example. I think, however, that it would be better to raise
a special exception if destructive methods are called,
but I don't have the picture clear enough to be able to tell.

> Maybe it is not the best idea
> to control the state at that global level?

Global level? What are you referring to?



>> Also, it would probably be good to have a means of determining
>> if a method call is safe to use, in the sense
>> that its result will always be the same object,
>
> You mean that the receiver will not be modified, right?

Well, not quite -- that's why I was struggeling for a new word for it.
The receiver can very well be modified, but only in a non-destructive way:
For example
   hash[key]
will always return the same object, no matter how many other 
key/value-pairs
will be added to hash.
So, I would say Hash#[] is always "permanent" (or "reliable" in my 
second post).
On the other hand, Hash#sort and Hash#size are not "permanent" (or 
"reliable").


>> - when the receiver is in the normal (unrestricted) state,
>>   method calls are "permanent", iff the receiver is an immediate value.
>
> Nope I am losing you, there are still non modifying methods as e.g.
> to_s so I guess I am wrong in my understanding.

Well, unless it is an immediate value, there is Object#replace,
and thus the object can be changed completely be another thread.
And thus, to_s will most certainly not be "reliable" or "permanent".
But we _can_ rely on Symbol#to_s and Fixnum#to_s, because immediate values
cannot be changed. (It is as if they are always frozen.)


>>   For example, we would definitely want to use Array#[],
>>   but this is only "permanent" for non-negative indices.
>
> You mean because -1 would be different because of growing might occur
> in a different thread. In that case permanent would mean insensible to
> growth?

Yes, I think you were able to put it better than I.
"permanent" / "reliable" = "insensible to anything that may happen, 
including growth"

And, so far we have not said anything about the resulting object itself.
One option would be to demand that the result must also (at least) be 
"semi_frozen".
For example, that a "semi_frozen" hash must only contain frozen and 
semi-frozen values.
But then, this restriction might be too strong, sometimes.
I think this is a minor issue at this point.


So long

Sven