From: Robert Dober <robert.dober@...>
Date: 2007-05-18T02:46:32+09:00
Subject: Re: "Crystallizing" Objects

On 5/17/07, Sven Suska <sven715rt@suska.org> wrote:
> 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?
Exactly what you described above, raise an Exception as soon as an
illegal operation on the object is performed; not depending on the
method.
Global was a bad name.
>
>
>
> >> 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:
Thats what I should have said, the concept is new and I find it
difficult to find the correct wordings.
> For example
>    hash[key]
> will always return the same object, no matter how many other
> key/value-pairs
> will be added to hash.
Agreed.
> So, I would say Hash#[] is always "permanent" (or "reliable" in my
> second post).
Ok, I see clearer now maybe constant might be a better word, but that
might be confusing for C++ folks.
> On the other hand, Hash#sort and Hash#size are not "permanent" (or
> "reliable").
Clear now.
>
>
> >> - 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.)
Aha sorry I think talking about the return value is not relevant or do
I still misunderstand?
>
>
> >>   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"
Great, I really see what is permanent now.
>
> 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".
Hmmm gotta think I see no reason so far for that!
> For example, that a "semi_frozen" hash must only contain frozen and
> semi-frozen values.
Sure but that is containment not return values?
> But then, this restriction might be too strong, sometimes.
> I think this is a minor issue at this point.
All this is open to investigation, you just introduced a concept...
>
>
> So long
>
> Sven
>
>
Cheers
Robert

-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw