Separating a Hash type from Object

P T Withington ptw at
Tue May 1 05:52:03 PDT 2007

On 2007-04-30, at 17:43 EDT, Andrew Dupont wrote:

> On Apr 30, 2007, at 2:20 PM, Alex Russell wrote:
>> There has been a proposal regarding this:
>> ISTM that exposing ES3's internal [DontEnum] to user-set properties
>> fixes the issue without removing the (useful) flexibility of the
>> object/hash duality.

Alex, can you say more about how this duality is useful?  An example,  

> This fixes for-in loops, more or less. I'd also like to see a Hash
> class with a custom iterator::get that yields only instance
> properties. Relying only on propertyIsEnumerable is not enough, I
> think, because naive script-writers won't necessarily know to mark
> their extensions to Object so as to keep their chocolate out of your
> peanut butter.

Agreed.  This solution relies on everyone behaving.

Would another approach be to have a way to tell for to enumerate only  
`hasOwnProperty` properties?

  for (var k in own foo) ...
  foreach (var i in own foo) ...


[This has the drawback that you cannot create 'inherited' hashes  
using prototypes.]

> However, it doesn't fix the lack of key safety.
> var foo = {};
> foo + ""; //-> "[object Object]"
> foo.toString = "bar";
> foo + ""; //-> Error: Can't convert foo to primitive type
> This bothers me.  The original "toString" property can still be
> accessed with an intrinsic:call, but that doesn't help with the
> automatic string coercion in the example above.
> I think this has been discussed before on this ML, but nobody has
> come up with an easy answer here.  Ideally, speaking from a narrow
> perspective, I'd like to be able to distinguish dot notation from
> bracket notation...
> foo["toString"]; //-> "bar";
> foo.toString;     //-> function() {}
> ... but I fear that's too large a can of worms to open.

Yow!  I have a better idea:  generic functions -- get methods out of  
instances altogether!

More information about the Es4-discuss mailing list