From: Robert Klemme <shortcutter@...>
Date: 2007-05-20T23:35:05+09:00
Subject: Re: "Crystallizing" Objects

--------------090102010705020002060103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 18.05.2007 22:34, Sven Suska wrote:
> Hello Robert,
> 
> thank you for your mail,
> however, I'm afraid that I haven't been able to grasp
> what you were up to.

Reading this posting and rereading your original posting it occurs to me 
that I probably misread your intentions and got on a completely 
different track: I believed you wanted a thread safe data structure that 
is initialized with a portion that is constant and shared by multiple 
threads which can extend it locally.  Apparently this is not what you 
want as I gather now.  I am sorry for the confusion.

Back to the original topic.  One bit that took me astray was your 
mentioning of "a third state of objects between frozen and normal" that 
should allow for growth only.  IMHO that concept is best described as a 
behavioral requirement, i.e. Hash#store and Hash#[]= must behave 
differently than normal as an example.  I believe this is best served by 
dedicated classes because you won't likely change the "mode" of 
operation of a single instance; also, if implemented as mode the 
implementation will be more complex than necessary.  Also, your "mode" 
differs quite a lot from frozen and not frozen because behavior will 
change depending on data structure while freeze just prevents instance 
variable assignment - and this is the same for all classes.

Your second requirement is to have the class thread safe, which can be 
achieved in different ways.  I believe most standard Ruby classes do not 
have built in thread safety on purpose: most of the time (i.e. when 
using it in a single thread) synchronization is just plain overhead. 
Another good reason not to build this into standard classes is that it's 
often not sufficient to synchronize individual methods (as you are 
probably aware because of the test and set scenarios needed for your 
growing data structures).  (You can observer a similar learning process 
in Java: the original collections Vector and Hashmap were synchronized 
while later collection classes did not have built in synchronization, 
instead there are wrapper classes that do the synchronization; even 
later on collections with specific synchronization properties were created).

Having said that, I believe the solution to your problem is not another 
mode between normal and frozen but a set of new classes (GrowingArray, 
GrowingHash etc., see attachment).  It's simpler to do (no change in the 
core of the interpreter necessary), more modularized and can be better 
adjusted to varying needs.  You can synchronize them as needed or even 
build synchronized variants.

Kind regards

	robert

--------------090102010705020002060103
Content-Type: text/plain;
 name="growinghash.rb"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="growinghash.rb"

require 'delegate'

class GrowingHash < DelegateClass(Hash)
  def initialize(*a,&b)
    super(Hash === a[0] ? a[0] : Hash.new(*a,&b))
  end

  def store(k,v)
    raise ArgumentError, "Key already set: #{k.inspect}" if key? k
    super
  end

  alias []= store

  def set_if_unset(k,v=nil)
    store(k, block_given? ? yield : v) unless key? k
  end
end

--------------090102010705020002060103--