Separating a Hash type from Object
peter.hall at memorphic.com
Wed May 2 11:44:10 PDT 2007
I'm wondering what is so wrong with Hash.set(key, value) and Hash.get(key)....
On 5/2/07, Brendan Eich <brendan at mozilla.org> wrote:
> 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.
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
More information about the Es4-discuss