Separating a Hash type from Object

Garrett dhtmlkitchen at gmail.com
Wed Jul 25 07:56:25 PDT 2007



Lars T Hansen-2 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), 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})
> 
What is Name? Is that a new type that I haven't seen yet? Looks like an
Identifier.
I don't see Name here:
http://developer.mozilla.org/es4/spec/chapter_19_native_objects.html
(That page could benefit from a TOC and alphabetization.)

> 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.
> 
The reason for adding them to Object.prototype is to have a common interface
for collections to compare objects with. The default behavior would be
strict equality.

set.add( new CaseInsensitiveString( "garrett" ) );

A comparator would also work. In absence of a comparator, sort objects by
their natural order and do equality checking.

The case for HashMap: HashMap is that it is the most common type of
collection that will be used. Dictionary is more flexible, but since the
keys are not, by default, strings, it will require more work to serialize
toJSONString. In most cases users will want Strings for keys. 

> 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 ;-)
> 
What about ByteArray, toString, toJSONString, valueOf, et c? If that's not
camelCase, I'm confused.

How does "Dictionary" sound?

> --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

-- 
View this message in context: http://www.nabble.com/Separating-a-Hash-type-from-Object-tf3671328.html#a11784195
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.




More information about the Es4-discuss mailing list