Rename Hash::fetch/store/exists to get/put/has?

[GoogleCodeExporter]

I've been keeping up with the recent ES4 discussion about Hash/Dictionary
objects. They use get/put/has/remove for the core methods. Should we change
to match these? base2 is not officially released yet and we are unlikely to
break anything. I can always create a simple patch to alias the old methods
anyway. What do you think? Too late to change? Or follow standards whilst
we still have time?

Original issue reported on code.google.com by dean.edw...@gmail.com on 27 Jul 2007 at 9:25

[GoogleCodeExporter]

There's still time. I'm feeling a bit sad, the object["property"] syntax can't 
be used, though ;-)

Also: don't you think the Hash.merge should do a "deep" merge (now it's 
overwriting members of the Hash type).

Original comment by doek...@gmail.com on 27 Jul 2007 at 10:41

[GoogleCodeExporter]

> I'm feeling a bit sad, the object["property"]
Are you talking about base2 or es4?

> don't you think the Hash.merge should do a "deep" merge

What do you mean by "deep" merge?

Original comment by dean.edw...@gmail.com on 27 Jul 2007 at 11:01

[GoogleCodeExporter]

//--| Shallow merge
var x=new Hash( { p:"doeke", a: { b:1 } } );
x.merge( { a: { c:1  } } );
x.fetch("a").b === undefined;    
x.fetch("a").c == 1;

the initial object of property a (b:1) is overwritten by the merge (c:1).

//--| Deep merge
var x=new Hash( { p:"doeke", a: { b:1 } } );
x.merge( { a: { c:1  } } );
x.fetch("a").b === undefined;    
x.fetch("a").fetch("b") == 1;    
x.fetch("a").c === undefined;
x.fetch("a").fetch("c") == 1;

So basically: inner Object objects are converted to Hash objects, and inner 
objects are also merged.
BTW: Arrays probably also need to support "merge".

Original comment by doek...@gmail.com on 28 Jul 2007 at 10:08

[GoogleCodeExporter]

I think we'll keep it as a shallow merge.

Any thoughts on the renaming?

Original comment by dean.edw...@gmail.com on 10 Aug 2007 at 4:19

[GoogleCodeExporter]

What are your thoughts one shallow merge? I accept your final vote, but if you 
don't give even one argument, my 
enthousiasm goes down...

My argument to support a deep merge is to support "options" (like in prototype) 
with hierarchy. For example, I have 
some options with http:

defaultOptions=new Dict({
      method: "GET",
      isAsync: true,
      username: undefined,
      password: undefined,
      headers: new Dict({"X-Requested-By": "base2.HttpTransport"})
});

The only reason to not support a "deep merge" is code size. But we could also 
make it optional:
  merge: function(values, deepMerge)

But I'm also happy to stick to my own Dict-implementation...

Thoughts on renaming: I just like the name "Dict", but I prefer standards more. 
I actually lost track of the 
Hash/Dict/HashMap/... discussion. Are the es4 method names decided on? 

Original comment by doek...@gmail.com on 11 Aug 2007 at 12:48

[GoogleCodeExporter]

Do you want to raise a separate issue for deep merging? I can always add it 
later.
The problem is that the merge() methods currently take multiple arguments. 
There is
also union() to consider, which is similar to merge().

> Are the es4 method names decided on? 

I lost track of that discussion too.

Original comment by dean.edw...@gmail.com on 11 Aug 2007 at 7:24

[GoogleCodeExporter]

> Do you want to raise a separate issue for deep merging? I can always add it 
later.
> The problem is that the merge() methods currently take multiple arguments. 

OK. We can always create a module with a deepMerge method or something. I think 
about it a bit more, before I 
raise an issue.

About naming: the new proposal seems stable (Brendan and Hansen seem resolute 
on this topic now): 
http://wiki.ecmascript.org/doku.php?id=proposals:dictionary

Method naming after java, the class is called "Map". I think we should rename 
both methods and class-name.

What do you think of the constructor opts?

Original comment by doek...@gmail.com on 11 Aug 2007 at 9:27

[GoogleCodeExporter]

The constructor ops alone make me think that this class should be separate from
Hash/Collection. base2's Hash class is very simple and basically just extends
JavaScript's Object class. I like the fact that the Hash constructor allows 
this:

var hash = new Hash({
  a: 1,
  b: 2
});

I think that we should rename store/fetch etc. Map can possibly be subclass of 
Hash
or Collection?

Original comment by dean.edw...@gmail.com on 12 Aug 2007 at 1:48

[GoogleCodeExporter]

Ha. Just noticed that Map has two constructors...

Original comment by dean.edw...@gmail.com on 12 Aug 2007 at 1:54

[GoogleCodeExporter]

I like the feature, the Map object allows to make the keys case insensitive 
(via the equals method). But we can 
do that via another mechanism.  What do you think?

I like the current constructor-format.

> I think that we should rename store/fetch etc.
Yeah.

> Map can possibly be subclass of Hash or Collection?

version 2.0 ;-)

Original comment by doek...@gmail.com on 12 Aug 2007 at 1:58

[GoogleCodeExporter]

I decided to go ahead with the renaming. This will be in the next update.

Original comment by dean.edw...@gmail.com on 30 Aug 2007 at 4:07

• Changed state: Started

[GoogleCodeExporter]

Original comment by dean.edw...@gmail.com on 30 Aug 2007 at 5:34

• Added labels: Type-Enhancement
• Removed labels: Type-Discuss

[GoogleCodeExporter]

Original comment by dean.edw...@gmail.com on 5 Dec 2007 at 4:48

• Changed state: Fixed