Separating a Hash type from Object

Brendan Eich brendan at
Mon Jul 30 10:08:22 PDT 2007

On Jul 30, 2007, at 8:54 AM, Garrett Smith wrote:

> [overquoting deleted]

> var stuff = new HashTable.<String, *>();
> stuff.add( "one", 1 );


> stuff.hasOwnProperty( "one" ); // false.
>;// undefined.
> "one" in stuff; // false.


> if( "one" in stuff.keys ) stuff.get( "one" ); // 1.
> for( var key in stuff.keys ) {
>   print( key + ": " + stuff[ key ] );
> }
> // one: 1.

Note: for (var key in stuff) is enough; for (let key in iterator::keys 
(stuff)) also works. You can iterate over values with

for each (let val in stuff) ...

And you can destructure items via

for (let [key, val] in iterator::items(stuff)) ...

for example. But this is all generic due to iterators and generators  
(whose last exported wiki page is way out of date).

> Should all Collections have a toJSONString?

Not necessarily, but that method delegates to Array.prototype or  
Object.prototype anyway, and as Lars noted the one in  
Object.prototype is generic. If it leaves out important properties  
due to the DontEnum attribute, that might be a clue that an override  
is needed. On the other hand there's no JSON type for Map, so you  
can't deserialize directly to a Map instance. You would have to  
convert using the |to| operator or a Map call or construction.

> Collection
>  |
>  +HashTable, SortedSet TreeMap ?

This is up to the larger ecosystem, but as with Python, the JS way,  
and the Web way (cf. mashups, which are not planned ahead of time to  
share named "types" broadly construed) favors protocols over single- 
inheritance nominal type trees. So collections might implement  
interfaces (either nominal, or more likely structural, types such as  
type iterator::IterableType).

>>>> (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 ;-)
> The current JS spec is camelCasing everything. I usually like it when
> an API does one thing consistently. If it's underscores, then always
> use underscore, et c. JavaScript (hey, that's camel'd, too!) alway
> uses camelCase. The DOM stuff is consistent, too (textContent,
> nodeValue, et c). Will adding an inconsistency add confusion?

There's no inconsistency at all -- types are InterCaps, methods are  
true camelCaps. Just like Java, after Smaltalk.


More information about the Es4-discuss mailing list