Sven Suska schrieb:

> to freeze the "already existing" data of an object
> and at the same time leave it open for "further growth".

> So, I think it would be beneficial to introduce a third state of objects
> between frozen and normal, like "growing" or "crystallizing" or
> "monotonous" or "incrementally_freezing" or "partially_frozen" ...

I'd better give a use case, to make clear what I mean:
Assume, we have a Hash called "users".

If it were just a normal hash, we would have to lock the object manually:

  if users.has_key(new_nickname)
    raise "Nickname already exists"
  end
  # hash could be modified here, if not locked!!!
  # if another thread would have stored a user with the same nickname
  # just now, then this data would be overwritten in the next statement.
  users[new_nickname] = user_data

If "users" were in this "partially_frozen" state, then we could write:

  begin
    users[new_nickname] = user_data
  rescue CantChangeExistingDataError
    raise "Nickname already exists"
  end

So, the prime use case is the assignment of hash keys.
Perhaps I was too quick generalizing this approach to all objects.



> 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,
> regardless of what other threads do to the receiver.
> (Let's say, it is a "permanent" method call)

"reliable" would probably be a better name for that.

And I think that this kind of check is not nessesary for my proposal to 
work.


Regards,
Sven