Separating a Hash type from Object

Garrett dhtmlkitchen at
Tue Jul 24 20:17:36 PDT 2007

Brendan Eich-2 wrote:
> On May 1, 2007, at 10:14 PM, Andrew Dupont wrote:
>> Brendan Eich wrote:
>>> I'm confused -- do you intend that foo#.toString name a property in
>>> no namespace with identifier 'toString' in some object, or a property
>>> in a hidden namespace with local name 'toString'?
>> The latter was my interpretation. But you're saying that the #.  
>> operator
>> would simply look at the subset of an object's properties that are
>> defined on the instance?
> Yes -- hence the direct:: namespace conceit that lost to #. #[ #{.
>> That's more reasonable than creating a whole new property  
>> namespace. It
>> doesn't solve the string coercion problem, though. Combining the #.
>> operator with "use namespace intrinsic;" would, but that means the
>> developer would have to *opt into* key safety.
> The key safety problems you cite are (a) matching toString or another  
> indirect (prototype-owned) property; (b) setting toString in the  
> directly referenced object to some value not a toString function.  
> You're right, #. addresses only (a).
> To address (b) would seem to require opting in as you note, or  
> changing the usual rules for hashes (objects created via #{...}) to  
> look for methods in a special namespace (intrinsic, or perhaps  
> function as in SpiderMonkey).
> This is a fair amount of magic for the Hash class, and some of it  
> (the function namespace) might want to be abstracted over any class,  
> since E4X's XML class in SpiderMonkey wants the ability to access XML  
> methods via, e.g., function::elements.
> Leaving (b) unsolved without opt-in (use namespace intrinsic), we  
> could avoid a Hash class with magic method lookup rules altogether,  
> and add #. #[ #{ as shorthand, where obj#.ident, obj#[expr] ,  
> obj#.ns::ident, and obj#.ns::[expr] would be variations on the  
> corresponding unsharp (hash-free) operators, which would work on any  
> kind of object by looking only in the directly referenced object, not  
> any prototype.

I see this as two issues. 

1) The need for Collections/Data Structures. 
2) The desire for shorthand access to these. 

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
  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 = 
  "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 function getKeys(deep: boolean = false) :
    iterator function getValues(deep: boolean = false) :
    iterator function getItems(deep: boolean = false) :
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
Quoted from:

View this message in context:
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at

More information about the Es4-discuss mailing list