I still like the idea of distinguishing "private" from "unique" names, where "private" = invisible via reflection & proxies and "unique" = visible via reflection & proxies (cf. the thread David linked to).
As for how direct proxies might help: yes, I've previously proposed several solutions: - One was to not allow proxies to trap private names, and always forward private name access unconditionally, as mentioned by Brandon. - The other was essentially Brendan's current proposal: if the trap is missing, forward the private name access to the target without converting it into a public object, except I also proposed factoring out private name access into separate "getPrivate"/"setPrivate" traps. See: https://mail.mozilla.org/pipermail/es-discuss/2011-December/018937.html https://mail.mozilla.org/pipermail/es-discuss/2011-December/018938.html Cheers, Tom 2012/4/19 David Bruant <bruan...@gmail.com> > Le 19/04/2012 01:54, Brandon Benvie a écrit : > > (or you simply don't trap the access, which is the route for >> [[prototype]], [[instanceof]], etc which now makes even more sense to me in >> light of this) >> > Not trapping seems like a valid option [1]. The rationale for the .public > counterpart in the private name proposal is that the proxy should not have > access to the private name. However, if it doesn't (directly or > indirectly), it can't do anything useful. Under these conditions, the trap > might as well not been called. > > David > > [1] https://mail.mozilla.org/**pipermail/es-discuss/2011-** > December/019005.html<https://mail.mozilla.org/pipermail/es-discuss/2011-December/019005.html> > > ______________________________**_________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
