Separating a Hash type from Object
brendan at mozilla.org
Wed May 2 10:53:47 PDT 2007
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.
More information about the Es4-discuss