search

pombreda / base2

Automatically exported from code.google.com/p/base2
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
> 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 commented 9 years ago 
//--| 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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
> 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 commented 9 years ago 
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 commented 9 years ago 
Ha. Just noticed that Map has two constructors...

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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