Separating a Hash type from Object

[Brendan Eich]

On May 2, 2007, at 4:58 AM, P T Withington wrote:

> On 2007-05-02, at 02:40 EDT, Brendan Eich wrote:
>   [...]
>> Indeed, #. etc. is just a thought experiment.
>
> I do think there needs to be a primitive Hash type.  Otherwise we
> doom users to trying to invent their own and hitting all the various
> pitfalls that have been enumerated on this thread.

I've agreed repeatedly, but without a sufficiently winning proposal  
(which I'm explicitly seeking here with help from y'all), it's not  
going to happen for ES4.

> The safety issue is that methods are visible as properties of an
> instance.  Putting the methods in a special namespace seems kludgey
> to me.  What is the benefit of methods being properties of an
> instance?  What if they were not?

Backward incompatible, requiring opt-in versioning and doubling  
brainprint. Why is this important to change incompatibly? Note that  
it's not just methods that make for the safety issue. There may be  
properties with other than function value in a prototype object.

> Another thought experiment:
>
> What if `foo.bar(...)` was syntactic sugar for `bar[typeof foo].apply
> (foo, ...)`.  Oh, wait, that's not quite right.  Guess I have to
> invent generic functions.  Hm.

We have generic functions (Array.map, etc.). That's not the issue.

Compatibility with ES1-3, as well as with standard OOP dogma, says  
that methods are called via obj.foo(). You could argue that should be  
sugar for some different dispatch mechanism, but ES1-3 do not  
distinguish methods from other properties. It doesn't matter whether  
they're delegated to a prototype, or directly in the object at hand.

/be