Separating a Hash type from Object

Lars T Hansen lth at acm.org
Tue Jul 24 23:57:32 PDT 2007


On 7/25/07, Garrett <dhtmlkitchen at gmail.com> wrote:
> I see this as two issues.
>
> 1) The need for Collections/Data Structures.
> 2) The desire for shorthand access to these.

Indeed.  We've decided to support (1) but not (2), but to sweeten our
solution by providing constructions and conversions from arbitrary
objects, so you can say

  new Dict.<Name,int>({a: 1, b: 2, c: 3})

or

  { a:1, b:2, c:3 } to Dict

and get what you want, namely, a map from names to integers
initialized with the three maps in the object literal.

We're discussing whether to accomodate a hashcode/equals protocol on
keys, but if so this is guaranteed not to be the only protocol, and
we're not putting these protocols into Object, which will likely
reduce their utility a little.

We're not providing weak refs.  In fact, Dict is implementable in ES4
without any implementation hooks at all.

(I don't much care for "Dict" as a name myself, but BiCaptialized
suggestions like HashMap and hashCode won't get you anywhere with this
committee ;-)

--lars

> Issue #1: The need for Collections/Data Structures.
>  a. A public interface for Dict has already been posted up. A link for
> ByteArray was posted. I would also like to see more collection types
> (SortedSet collection, and some sort of Enum).
>  b. The need for hashCode and equals methods on Object.prototype (DontEnum).
>  c. The need for overridden implementations of toJSONString on a Collection.
> Method hashCode is more suitable for valueOf for hashes; valueOf is not
> required to return an int does not return an int for string or Function
> objects.
>   I would really like to see these issues addressed in further discussion.
>
> Issue #2: The desire for shorthand access to a HashMap.
> HashMap is a better name. "Dict" just doesn't roll off the tongue nicely.
> Sad to say, this could get a smart programmer in deep trouble.
>
> HashMap (Dictionary) shorthand delegates to a HashMap's get/set methods.
>
> The set method is called in a literal expression syntax by specifying a
> property name.
>
> var foo =
> #<String>{
>   "toString" : "i'm a monkey."
>  // ,boo : 1 // TypeError.
>   ,flavor : "banana"
> };
>
> foo.toString( ); // Returns String representation of a Dict (presuming foo
> is error-free).
> foo.hasOwnProperty( "flavor" ); // false.
> foo.flavor; // undefined.
> foo.get( "flavor" ); // "banana"
> foo.get("toString"); // returns "i'm a monkey."
>
> /* fooTwo has no type specified. Here, we
>  *  default behavior using ToObject, et c for literals.
>  */
> var fooTwo = #{
>   "toString" : function meowLikeADoggy(){ return this.sound; }
>   ,"sound" : "moo"
>   ,"hasOwnProperty" : function alwaysWrong( prop ) {
>     return !this.hasOwnProperty( prop ); // This function is not bound at
> this point.
>   }
> };
>
> fooTwo.get( "hasOwnProperty" ); // function.
> fooTwo.hasOwnProperty( "hasOwnProperty" ); // false.
> fooTwo[ "hasOwnProperty" ]; // Do we look in HashMap's keys or look in the
> object itself?
>
> var bar = {
>   "toString" : "a monkey's uncle" // don't call me.
> };
>
> bar.toString(); // Error
>
> Creating a HashMap with literal syntax would create one of these:
> (by Lars T Hansen)
>
> class HashMap.<Type> {
>     function HashMap(weak: boolean = false)
>     public function from(x : Object!)
>     public function size() : uint
>     public function get(key: String) : Type?
>     public function put(key:String, value:Type) : void
>     public function has(key:String) : boolean
>     public function remove(key:String) : boolean
>     iterator function get(deep: boolean = false) :
> iterator::IteratorType.<String>
>     iterator function getKeys(deep: boolean = false) :
> iterator::IteratorType.<String>
>     iterator function getValues(deep: boolean = false) :
> iterator::IteratorType.<Type>
>     iterator function getItems(deep: boolean = false) :
> iterator::IteratorType.<[String,Type]>
> }
> I would like to not have the delete operator call the remove() method; this
> would seem to add confusion.
>
>
> > /be
> > _______________________________________________
> > Es4-discuss mailing list
> > Es4-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es4-discuss
> >
> >
> Quoted from:
> http://www.nabble.com/Separating-a-Hash-type-from-Object-tf3671328.html#a10280414
>
> --
> View this message in context: http://www.nabble.com/Separating-a-Hash-type-from-Object-tf3671328.html#a11775536
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list