On Mar 2, 2015, at 9:22 AM, Rick Waldron wrote: > > > On Sun, Mar 1, 2015 at 4:17 AM Leon Arnott <[email protected]> wrote: > On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock <[email protected]> > wrote: > If you want both a TCP-able from and a local (most closely enclosing callable > thing) form then the later should also presumably also be applicable at the > top level of functions. > > The 'in' meta property prefix in combination with the 'function' prefix > could do that job: > > > One thing I feel about meta-properties is that they really should have some > connection to the keyword's normal meaning, as is true of new.target. "in" > currently exclusively refers to inherited property access, both as an > operator and as a for-in keyword, and repurposing it to mean "invocation" > when there's a meta-property attached is, well, not something I'd be proud of > explaining. > > Strong agreement here. If `in` grows meta properties, they should by relevant > to what the `in` operator does (which may mean none at all). >
I'd agree, in an ideal world. But we have such a limited set of reserved words available that I'm not sure we can afford to be so choosy. In the end, the choice may be between meta property names that violate your proposed principle or not providing any way to access the corresponding value. In my proposal, I choose "function" as a prefix because it was suggestive of function objects, rather than definitions that begin with keyword 'function'. For example, concise methods are more similar to 'function' functions than they are to arrow functions, but they aren't declared using the 'function' keyword. I think that wanting to have both TCP-able form and an immediately enclosing form may be going a step too far in complexity. And it certainly puts an additional strain on the selection of the prefix keyword. If we;have to choose just one, I chose providing access to the immediately enclosing function object and its argument information over the TCP-able form. The reason is that within the non-TCP-able from form, local renames can be used to make outer meta properties accessible to inner functions. But if all you have is the TCPable form then these is no way for an arrow functions to access its own meta properties. And arguably, that is the key new functionality. I still think that what I present in my proposal is a good balance both in terms of both naming and in terms of what new information is being made available to ES code Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
