Separating a Hash type from Object

Lars T Hansen lth at acm.org
Wed Jul 25 02:28:27 PDT 2007


On 7/25/07, Lars T Hansen <lth at acm.org> wrote:
> 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),

I should say, the current proposal supports (1) but not (2), and has
the features outlined below, but has not yet been approved.

--lars

> 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