------art_59685_5834295.1168711996596
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/13/07, Martin DeMello <martindemello / gmail.com> wrote:
>
> On 1/13/07, Mauricio Fernandez <mfp / acm.org> wrote:
> >
> > Do you feel that store_{once,new,unique} is too long?
> > (I have a slight preference for "once"; "unique" seems a bit puzzling
> since it
> > seems to refer to the key, which is always unique)
>
> Even 'store_once' seems to refer to the value rather than the pair,
> which is why I like "underlay" - it suggests that if there is
> something already in the hash, it will mask the value you are trying
> to add.
>
> martin
>
>
I think that Tom's idea to have a method doing what he suggests is a bright
one, but we seem to fail to be able to find a convincing name, maybe in that
case a different approach might be worth being considered.
Look at the following code, just for readability if something hits you than
one could discuss philosophical issues ;)

h.store(k, v, :overwrite false)
h[k, :overwrite false]  
or
h[k, :noglobber ]  
or
h.store(k, v, :globber false)

Now you decide for yourself what is readable and define your conveniance
method in ::Hash.

For those strictly opposed to overcrowding the Hash#store interface and they
have their points of course
although we are perfectly backward compatible

h.insert(k, v,  :overwrite false)
etc.etc.

Although insert is not a better name than before - it is not a bad name
anyway Tom, but I agree with Maurizio that it is just not good enough :( -
its call syntax for the special behavior makes it quite readable.

I guess I'll file a RCR,   JUST KIDDING!!!

Robert


-- 
"The best way to predict the future is to invent it."
- Alan Kay

------art_59685_5834295.1168711996596--