On Sat, Jan 28, 2012 at 6:58 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
> I don't think we would ever want to expose __proto__ as an accessor > property on Object.prototype as that would expose set/get functions that > would also have the capabilities of __proto__ without being associated > with that special property. > As long as they are restricted to objects from their frame of origin, I don't see much wrong with it. Again, I have come to prefer Brendan's non-accessor approach, but I don't see any strong reason to prefer one over the other. From a SES security POV the difference matters not at all, since the first thing the SES initialization would do in such a frame is to delete __proto__ anyway. > > I can easily write a specification for __proto__ that essentially has the > SpiderMonkey observable behavior (including exposing a data property on > object prototype) without mandating the observable use of accessor > properties or any other specific implementation mechanism. How you go > about invisibly implementing it would be up to you. Since most > implementations already seem to have special mechanism for giving "magic" > behavior to certain properties I would expect them to use some of those > mechanisms here. > > Allen > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
