On Thu, Dec 10, 2009 at 9:05 PM, Maciej Stachowiak <[email protected]> wrote:
> It looks like I plied too many clauses and prepositional phrases into once
> sentence. Let me try to rephrase:
> If you want to emulate a DOM object that has catchall properties, then it
> needs to return true for hasOwnProperty() for the things that should be own
> properties. If you want to build that emulation in pure ECMAScript (perhaps
> as a security façade), then you need a catchall mechanism that lets the
> object appear to have own properties as seen through hasOwnProperty. It
> seems like the proposed mechanism as described does not allow this -
> assuming I understood your initial comment quoted above correctly.
Good. You did understand me correctly. Now that I understand you, I
agree that this is a design goal of our mechanism.
Before proposing a fix, let me check if I understand the nature of the
problem. Are you saying that, given that d either is a DOM object with
an own property "name" or d is an emulation of such a DOM object, that
not only must
d.hasOwnProperty(name)
be true, but so must
Object.prototype.hasOwnProperty.call(d, name)
? I think I agree this is a reasonable requirement, since many JS
programmers have learned to call hasOwnProperty "statically" in this
manner. What about Object.prototype.propertyIsEnumerable? In the
current state of our proposal, it is as meta as
Object.prototype.hasOwnProperty. Before fixing
Object.prototype.hasOwnProperty, I'd like a better sense of whether
Object.prototype.propertyIsEnumerable needs to be fixed as well.
Thanks.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
