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

[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 12 Aug 2007 at 1:48

[GoogleCodeExporter]

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

Original comment by [email protected] 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 [email protected] 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 [email protected] on 30 Aug 2007 at 4:07

• Changed state: Started

[GoogleCodeExporter]

Original comment by [email protected] on 30 Aug 2007 at 5:34

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

[GoogleCodeExporter]

Original comment by [email protected] on 5 Dec 2007 at 4:48

• Changed state: Fixed