I send a new topic message about the following, but for some reason it seems slow getting to es-discuss. So, I'm trying it via a replay:
Here is a new proposal for some additional meta properties that should be considered for ES7 https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md On Feb 26, 2015, at 12:19 PM, Mark S. Miller wrote: > On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi > <[email protected]> wrote: > `callee` could be spec'd similar to `super` and transpiled or resolved > statically instead of dynamically, but `callee.caller` or in general the > function `caller` raised many security concerns, giving you the ability to > reach objects you probably shouldn't have. > > These two were different beasts, but `callee` for numerous reasons, and > specially for anonymous and non referenced Object methods syntax, is really > leaving a hole in the language, IMO > > > To respond to this, I searched in vain for the following message on > es-discuss, only to find it in a private thread. This message helped > contribute towards the syntactic direction we finally took, where allowable > new meta-accesses are introduces by <keyword>.<identifier>, but only for > keywords that are not valid expressions by themselves. ES6 contains the first > example of this in "new.target". Many thanks to David Herman for this > generalization -- I didn't see it at all. > > Note that most of the meta.* proposals I list below I am not advocating -- > indeed I think most are probably bad ideas. I include them only as examples > of what lexical context meta accesses could be soundly added to the language > as special forms. > > For the record: > > > ---------- Forwarded message ---------- > From: Mark S. Miller <[email protected]> > Date: Fri, Jan 2, 2015 at 5:10 PM > Subject: Re: Subclassing Builtins > > > [...] close but not quite. E has a lexical reflective access special form > that gives quite a lot of access -- the "meta" keyword. The important > features that make it non-objectionable: > > a) Its usage patterns is to extract from it the more specific reflective > access needed for each use. > b) Its API is designed to encourage such authority division on use. > c) It is understood and documented from the beginning as giving broad access, > so hopefully no one will mistake it for providing less access than it does. > > So, hypothetically, if, say, we introduced "meta" as such a special form to > JS, then > > "meta.arguments" could provide arguments. > "meta.originalContructor" could provide the original constructor. > "meta.callee" could provide access to the function it appears in. > "meta.source" could provide access to the source code of the function it > appears in. > "meta.strictness" could be a boolean indicating the strictness of the code it > appears in. > "meta.environment" could provide a Map from variable name to value reflecting > the lexical scope at the place it appears. > > More dangerously but still plausibly > "meta" could provide an object with the above fields. The reason it is more > dangerous is that passing "meta" might give access to a field added in a > later spec. The reason it is still plausible is that passing "meta" itself, > unlike passing "arguments" or "meta.arguments", would be understood as > passing broad access. > > However, > "meta.caller", as something that provide[s] access to the current > activation's caller, must still be forbidden. > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
