import.meta and TC39 process as a whole

[Matthew Robb]

I really can't find a good resource on direct vs indirect evaluation but my
understanding is it's one of the main considerations for using a keyword
over an identifier for contextual information. One example which is already
in the language would be 'eval' which you can read a little about here:
http://2ality.com/2014/01/eval.html

Now you might be able to have an API that gets you the same result as the
context sensitive keywords but it would be less ergonomic among other
things: Reflect.getModuleMetaProperty(someModuleNs, 'propName') but this
becomes much more difficult to do FROM WITHIN THE MODULE ITSELF. Anything
that is, let's call it tangible, cannot receive implicit contextual
information it must have something passed to it that it would use to look
up said information.

Sure there could be arguments made about introducing new environment type
records to the top level module scope of all modules but this is
potentially much more error prone and likely to lead to more and bigger
questions down the road. 'module' in particular is a really bad choice imo
as node/commonjs have already introduced a 'module' identifier into all of
their module scopes hence `module.exports = ...`. There may be solutions to
working around that in one form or another BUT the 'trend' in TC39 to use
keyword meta properties for context sensitive information is to avoid
solving ever edge case of conflict that would impact existing code and
users. It really is a fairly ripe space for powerful and ergonomic features
like `super` which feel like "magic". The same is true for import.meta but
it may be harder to identify right off as the uses haven't all been fully
introduced such as environment specific properties and potentialy other
loader hooks.

NOW as I was writing this it came to mind that we DO have a new syntactic
form for private data coming in the form of private fields which use a hash
prefix. It would be interesting to explore using the same syntax for module
scoped private fields:

```js

console.log(#dirname);
```


- Matthew Robb

On Sat, Aug 5, 2017 at 12:35 PM, Dmitrii Dimandt <dmitrii at dmitriid.com>
wrote:

> Too bad emails don’t have "thumbs up" and “+1”s :) So here’s my "+1” to you
>
>
>
> On Sat, 05 Aug 2017 at 18:28 "T.J. Crowder" <">"T.J. Crowder" > wrote:
>
>> On Sat, Aug 5, 2017 at 5:05 PM, Dmitrii Dimandt
>> <dmitrii at dmitriid.com> wrote:
>> > So, in my opinion, the argument for not adding new global entities
>> > such as System, or Module, or Loader (or heck, even all three of
>> > them) being “these are not keywords, we can’t introduce them” is
>> > really really weak.
>>
>
> Is anyone making that argument? I certainly am not. Not only is it
> possible to add more global entities, as you point out, it's been done
> repeatedly: `Symbol`, `Reflect`, etc. They just can't be *keywords* without
> breaking things. They have to be identifiers. Which means they have
> bindings with values. Which means those values can be copied. Which has
> implications.
>
> On Sat, Aug 5, 2017 at 5:08 PM, Dmitrii Dimandt
> <dmitrii at dmitriid.com> wrote:
> >
> > That’s not what I was really aiming at :)
> >
> > The original concern was “to get ‘module’ : 1. It's a
> > context-sensitive keyword, and code that's using it needs to
> > be updated when migrated to a module. “
> >
> > I was just pointing out that ‘import’ is already a context-
> > sensitive keyword (as are a bunch of others, like super.
> > Is super a keyword BTW?)
>
> My point was that this would be the only case I know of where it would be
> a keyword in one context but an identifier in another in the *exact same
> production*. `super`, `import`, etc., are **always** keywords. You just
> can't use them except in certain contexts. So I shouldn't have said
> "context-sensitive keyword" so much as "keyword or identifier depending on
> context." (But then...I did, earlier; I figured the shorthand was okay
> after spelling it out longhand. :-) )
>
> But again: Maybe that's feasible. Or maybe it's not a problem passing the
> value around, in which case a predefined `module` identifier only in module
> code isn't a problem anyway.
>
> -- T.J. Crowder
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170805/c73e05bd/attachment.html>