> Nothing stops you from *explicitly* defining behaviour for `import.meta`.
Nothing stops you from *explicitly* defining behaviour of
Reflect/Proxy/Symbol/what-have-you.

> However, when the question comes to, say, replacing `import.meta` with
`X.y.z`, it becomes nigh impossible.

As has been mentioned many times, backward-compatibility of a critical
feature of JS. We can't take over the behavior of a random variable have
have it do something else because it can break existing code. Other
features are done carefully to avoid this issue, but your proposal does not
avoid that.

> Here’s `import.meta` semantics rewritten for X.y.z.

> X.y.z available only in module context. Usage outside raises a
SyntaxError.

That will break existing code, making it immediately a no-go.

On Sat, Aug 5, 2017 at 3:09 PM, Dmitrii Dimandt <dmit...@dmitriid.com>
wrote:

> Honestly, I’ve seen the “you learn new thing and move on” so many times,
> I’m getting tired of it.
>
> I have ~10 years of experience with PHP and ~5 years of experience with
> Coldfusion. Both experiences are pre-2010 (both languages somewhat improved
> since then, even though I don’t know whether Coldfusion is still being
> developed).
>
> Both are, or were, *horrible* languages. Both were, no doubt, driven by
> “you learn new things and move on”. Probably the reason why Coldfusion in
> its script form didn’t have “less than” and “greater than” expressed as “<“
> and “>”. You had to write “gt”, “gte”, “lt”, “lte”. Loads of fun. `if (x gt
> y)` etc.
>
> Another argument I really don’t get is “oh, you can’t have an object, it
> will have to change access rules” or “import.meta isn’t a variable, it has
> access to local context, you can’t have that with global objects” or some
> such.
>
> It’s just grammar isn’t it? Somehow nothing stops you from *explicitly*
> defining a thing called `ImportCall` to randomly turn a static keyword into
> a function-like import(). Nothing stops you from *explicitly* defining
> behaviour for `import.meta`. Nothing stops you from *explicitly* defining
> behaviour of Reflect/Proxy/Symbol/what-have-you.
>
> However, when the question comes to, say, replacing `import.meta` with
> `X.y.z`, it becomes nigh impossible. “Changing property access rules” and
> all that. Somehow changing how keywords are treated is of no concern
> though. Somehow introducing and explicitly defining behaviour for new
> global objects is no biggie. But don’t you dare touch `import()`,
> `import.meta`, `function.sent`. These are holy cows and their behaviour
> cannot be implemented in any other way than in “this new thing that you
> learn and move on”.
>
>
> Here’s `import.meta` semantics rewritten for X.y.z.
>
> Introduction
>
> X.y.z
>   Object | undefined
>   An object exposed through the X.y.z property. Concrete subclasses of the
> Abstract Module Record specification type are expected to fill this field
> when creating the Module Record, usually by delegating to the host
> environment. It is undefined by default, but must become an Object before
> it is ever accessed by ECMAScript code.
>
>   X.y.z available only in module context. Usage outside raises a
> SyntaxError.
>
>
> (somehere in Left-Hand-Side Expressions I guess, too late for me to sift
> through the standard)
> XYZ :
>    X.y.z
>
> Module semantics
>
> 1.1.2 Source Text Module Records
> 1.1.2.1 ModuleEvaluation( ) Concrete Method
> The ModuleEvaluation concrete method of a Source Text Module Record
> performs the following steps:
>
> - Let module be this Source Text Module Record.
> - Assert: ModuleDeclarationInstantiation has already been invoked on
> module and successfully completed.
> - Assert: module.[[Realm]] is not undefined.
> - If module.[[Evaluated]] is true, return undefined.
> - Set module.[[Evaluated]] to true.
> - For each String required that is an element of
> module.[[RequestedModules]], do
> - Let requiredModule be ! HostResolveImportedModule(module, required).
> - NOTE: ModuleDeclarationInstantiation must be completed prior to invoking
> this method, so every requested module is guaranteed to resolve
> successfully.
> - Perform ? requiredModule.ModuleEvaluation().
> - Let moduleCxt be a new ECMAScript code execution context.
> - Set the Function of moduleCxt to null.
> - Set the Realm of moduleCxt to module.[[Realm]].
> - Set the ScriptOrModule of moduleCxt to module.
> - Assert: module has been linked and declarations in its module
> environment have been instantiated.
> - Set the VariableEnvironment of moduleCxt to module.[[Environment]].
> - Set the LexicalEnvironment of moduleCxt to module.[[Environment]].
> - Suspend the currently running execution context.
> - Push moduleCxt on to the execution context stack; moduleCxt is now the
> running execution context.
> - Let importMeta be ObjectCreate(null).
> - Let importMetaValues be ! HostGetImportMetaProperties(module).
> - For each Record {[[Key]], [[Value]]} p that is an element of
> importMetaValues,
> - Perform ! CreateDataProperty(importMeta, p.[[Key]], p.[[Value]]).
> - Perform ! HostFinalizeImportMeta(importMeta, module).
> - Set module.[[ImportMeta]] to importMeta.
> - Let result be the result of evaluating module.[[ECMAScriptCode]].
> - Suspend moduleCxt and remove it from the execution context stack.
> - Resume the context that is now on the top of the execution context stack
> as the running execution context.
> - Return Completion(result).
>
> etc.
>
>
> On Sat, 05 Aug 2017 at 23:50 Logan Smyth <Logan Smyth
> <logan+smyth+%3cloganfsm...@gmail.com%3E>> wrote:
>
>> > The thing is, I clearly provide arguments in favour of my opinion.
>> >
>> > We now have:
>> > - keywords that are just keywords, really (typeof, case, break, etc.)
>> > ...
>>
>> Totally fair. I understand that's where your coming from.
>>
>> > How can adding “properties” to semantically fundamentally different
>> things elegant? Or increasing the number of extremely context-dependent
>> things? Or overriding existing keywords with new and exceedingly confusing
>> behaviours?
>>
>> This is an argument for literally never changing the language. New things
>> always seem confusing at first, then you learn and move on.
>>
>> > Riiiight. Because import.meta is not a magically-populated
>> not-quite-global variable. Oh. Wait. That’s *exactly* what it is.
>>
>> `Introspect` is a variable with well-defined existing behavior as a
>> variable. `import` is not a variable, it has no meaning when used as a
>> value until the spec assigns it a behavior. That is the point I'm trying to
>> get across. Is it less than ideal? Yeah, having `module` as a keyword would
>> be perfect, but we have to work within the bounds of the language that we
>> have.
>>
>> > Even though it’s worse. import is a not-really-a-function-not-real
>> ly-an-object-not-really-a-static-not-really-a-dynamic-keyword which is
>> clearly far worse than a properly defined API.
>>
>> What is a properly defined API for this case? Access to `.meta` needs to
>> be able to know what module you are inside of. It needs some kind of
>> context that ties it to the file that is asking for metadata. Within the
>> existing behavior of the language, we can't just make a new global
>> object like `Symbol` or `Reflect` because it has no way to know what file
>> is asking for metadata.
>>
>> The options are either:
>>
>> * Add new syntax to expose the per-module-specific information, like
>> `import.meta`, which cannot conflict with any existing code.
>> * Co-opt existing property-access behavior to make it behave differently
>> from how it would in other contexts, like `Introspect.context`. It would
>> either have to introduce an entirely new keyword, which as I mentioned is a
>> breaking change, or it would have to fundamentally override the behavior of
>> accessing a property on an object to allow the object to know what module
>> the property was accessed from.
>>
>> Since new keywords are out the window, I guess it could be said that the
>> argument here are two sides, one arguing for more syntax to keep the
>> execution model simple (import.meta) vs keeping the syntax simple at the
>> expense of making the runtime behavior of the code more complex by changing
>> how property access works.
>>
>> I fall on the side of syntax because changing the behavior of property
>> access to expose the current file seems massively more complex and seems
>> much more likely to me to confuse people.
>>
>>
>> On Sat, Aug 5, 2017 at 2:29 PM, Jordan Harband <ljh...@gmail.com> wrote:
>>
>>> > There’s no code anywhere which doesn’t have an object called Symbol
>>> invoked with `new Symbol()`?
>>> Any such code would either have a local `Symbol`, would have defined a
>>> global `Symbol` that shadowed any pre-defined one (including the new global
>>> in ES6), or would have thrown a ReferenceError or TypeError. Adding
>>> `Symbol` won't break any of that code (because the code that threw was
>>> already broken).
>>>
>>> On Sat, Aug 5, 2017 at 2:20 PM, Dmitrii Dimandt <dmit...@dmitriid.com>
>>> wrote:
>>>
>>>> > [Reflect] Not a breaking change because adding a new global isn't new
>>>> syntax, it's just a new variable that exists and essentially can't break
>>>> much.
>>>>
>>>> It either isn’t a breaking change, or can’t break much. It cannot be
>>>> both.
>>>>
>>>> > Not a breaking change because this constructor did not exist before.
>>>>
>>>> Are you entirely sure? There’s no code anywhere which doesn’t have an
>>>> object called Symbol invoked with `new Symbol()`? The moment you add a
>>>> global anything, you break someone’s code somewhere.
>>>>
>>>> > I don't think I'd call super properties metaproperties for this
>>>> reason. `super` property access is its own class-related syntax that isn't
>>>> related. I do think it sets a perfectly reasonable guideline that makes it
>>>> clear most people have no problem accessing properties off of keywords.
>>>>
>>>> I fail to see where you see guidelines specced out in the
>>>> specifications of metaproperties or superproperties. “Most people” end up
>>>> just stuck with these because they are either unaware that these changes
>>>> are coming or are not active enough to voice their concerns.
>>>>
>>>> > The biggest issue for me in this whole thread is that it's all
>>>> extremely opinion-based. What one person calls complex another would call
>>>> elegant.
>>>>
>>>> The thing is, I clearly provide arguments in favour of my opinion. Let
>>>> me just summarise them for you.
>>>>
>>>> We now have:
>>>>
>>>> - keywords that are just keywords, really (typeof, case, break, etc.)
>>>> - keywords that are just keywords, but don’t even exist in a language.
>>>> They are reserved for future use in various contexts: always reserved, only
>>>> in strict mode, only in module code etc. (enum, public, private, await
>>>> etc.). May never be used and may possibly be removed, as some keywords have
>>>> been (int, byte, char etc.)
>>>> - literals that are basically keywords (null, true, false)
>>>> - non-keywords that are for all intents and purposes keywords (eval,
>>>> arguments)
>>>> - keywords that look like objects (because they have additional
>>>> properties) which are not objects (new with new.target)
>>>> - keywords that look like functions (because they are invoked like
>>>> functions and return values like functions) which are not functions (import
>>>> and import())
>>>> - keywords that look like objects *and* functions but are neither
>>>> (import and import() and import.meta)
>>>>
>>>> It gets even worse. Because “metaproperties” are not just attached to
>>>> keywords. They are attached to keywords which have *fundamentally different
>>>> semantics* in the language:
>>>> - `new` is an operator[2], it gets `new.target`
>>>> -  A function is a callable object [3], and it gets a `function.sent`
>>>> - import is … I don’t know what import is. It gets transformed into a
>>>> separate, made-just-for-import CallExpression and then it gets an
>>>> `import.meta` on top of that (as a hardcoded “metaproperty”).
>>>>
>>>> All of the above are basic facts about the language as it exists now.
>>>> How can adding “properties” to semantically fundamentally different things
>>>> elegant? Or increasing the number of extremely context-dependent things? Or
>>>> overriding existing keywords with new and exceedingly confusing behaviours?
>>>>
>>>> > > So there’s really *nothing* stopping you from designing a proper
>>>> System/Module/Loader/Introspect/Avocado or any subset thereof instead
>>>> of slapping “metaproperties” on everything in sight :)
>>>> >
>>>> > I don't think anyone has claimed that `import.meta` is meant as a
>>>> replacement for these. We still need a loader spec
>>>>
>>>> and a System spec and an Introspect spec, and ... That is why all these
>>>> random additions to vastly different things in the language look like
>>>> ad-hoc shortsighted solutions with no respect for the language or its
>>>> evolution. “We need a thing, we have nowhere to put this thing, let’s add
>>>> this thing to a keyword, because new.target (bad design) has opened a door
>>>> for us”.
>>>>
>>>> > I'd _much_ rather have a static syntactically-defined way to access
>>>> that information over a magically-populated not-quite-global variable like
>>>> `Introspect.context.sent`.
>>>>
>>>> Riiiight. Because import.meta is not a magically-populated
>>>> not-quite-global variable. Oh. Wait. That’s *exactly* what it is.
>>>>
>>>> Even though it’s worse. import is a not-really-a-function-not-real
>>>> ly-an-object-not-really-a-static-not-really-a-dynamic-keyword which is
>>>> clearly far worse than a properly defined API.
>>>>
>>>>
>>>> On Sat, 05 Aug 2017 at 22:37 Logan Smyth <Logan Smyth
>>>> <logan+smyth+%3cloganfsm...@gmail.com%3E>> wrote:
>>>>
>>>>> `await` could be added because there is no case in existing code where
>>>>> `await <expression>` would have been valid code, so it is
>>>>> backward-compatible. The same applies for all of the meta-property
>>>>> proposals. The same is not true for `Introspect.context.module`. It's not
>>>>> just a question of it a given construct could be made to behave the way 
>>>>> you
>>>>> want, it's also a question of it it would be compatible with existing 
>>>>> code.
>>>>>
>>>>> > Introduced in ECMASCRIPT 2015: Reflect is a built-in object that
>>>>> provides methods for interceptable JavaScript operations.
>>>>>
>>>>> Not a breaking change because adding a new global isn't new syntax,
>>>>> it's just a new variable that exists and essentially can't break much.
>>>>>
>>>>> > Introduced in ECMASCRIPT 2015: The Symbol() function returns a value
>>>>> of type symbol, has static properties that expose several members of
>>>>> built-in objects, has static methods that expose the global symbol
>>>>> registry, and resembles a built-in object class but is incomplete as a
>>>>> constructor because it does not support the syntax "new Symbol()”.
>>>>>
>>>>> Not a breaking change because this constructor did not exist before.
>>>>>
>>>>> > ECMAScript 5 introduced: yield, let
>>>>>
>>>>> Not a breaking change because those two can only occur in locations
>>>>> where they can't conflict with existing ES5 code. The extremely limited
>>>>> cases where `let` _could_ be in conflict are explicitly handled in the
>>>>> grammar to prevent breaking changes.
>>>>>
>>>>> > ECMASCRIPT 6 introduced: await as a reserved word in module code
>>>>>
>>>>> Same as above.
>>>>>
>>>>> > So, introducting new things into the language is not really such a
>>>>> big problem as it’s made out to be ;)
>>>>>
>>>>> No-one said introducing things was not possible, but we can't break
>>>>> existing code.
>>>>>
>>>>> > Don’t forget that `super` gets its own properties. Since there’s no
>>>>> specification of what “metaproperties” are, they are just called
>>>>> superproperties[7] in the grammar. Because reasons.
>>>>>
>>>>> I don't think I'd call super properties metaproperties for this
>>>>> reason. `super` property access is its own class-related syntax that isn't
>>>>> related. I do think it sets a perfectly reasonable guideline that
>>>>> makes it clear most people have no problem accessing properties off of
>>>>> keywords.
>>>>>
>>>>> > The problem with “metaproperties” is that they make the language
>>>>> more complex, chaotic and make it difficult to reason about the language.
>>>>>
>>>>> This seems to be the core of your argument, but I honestly don't quite
>>>>> see why it is more complex/chaotic. The biggest issue for me in this whole
>>>>> thread is that it's all extremely opinion-based. What one person calls
>>>>> complex another would call elegant.
>>>>>
>>>>> What specifically is difficult to reason about that wasn't already
>>>>> complex? Same for `function.arguments`. You're saying you think it's 
>>>>> better
>>>>> to have an automatically-created `arguments` variable in every single
>>>>> function instead of having syntax to access it? `arguments` and `this` as
>>>>> two auto-initialized bindings are some of the most confusing parts of JS.
>>>>>
>>>>>
>>>>> > So there’s really *nothing* stopping you from designing a proper
>>>>> System/Module/Loader/Introspect/Avocado or any subset thereof instead
>>>>> of slapping “metaproperties” on everything in sight :)
>>>>>
>>>>> I don't think anyone has claimed that `import.meta` is meant as a
>>>>> replacement for these. We still need a loader spec, but having a syntactic
>>>>> way to access data about the current active module is absolutely a useful
>>>>> thing to have. It's no different than CommonJS's __dirname and __filename
>>>>> among others. The logic for implementing a loader is separate from the
>>>>> logic for defining the behavior of module execution itself.
>>>>>
>>>>> I'd _much_ rather have a static syntactically-defined way to access
>>>>> that information over a magically-populated not-quite-global variable 
>>>>> like `Introspect.context.sent`.
>>>>> In a perfect world absolutely `module` could have been a keyword, but at
>>>>> this point making that change seems like an absolute no-go because it 
>>>>> could
>>>>> easily break existing code.
>>>>>
>>>>> > Like look. function.sent?? Really? And it’s extremely highly
>>>>> context-specific: “function.sent can appear anywhere a YieldExpress would
>>>>> be legal. Referencing function.sent outside of a GeneratorBody is a Syntax
>>>>> Error.”
>>>>>
>>>>> It's the exact same context-specific behavior as `yield` and they are
>>>>> both tied to generator functions. How is that in any way unexpected?
>>>>>
>>>>>
>>>>> On Sat, Aug 5, 2017 at 12:43 PM, Dmitrii Dimandt <dmit...@dmitriid.com
>>>>> > wrote:
>>>>>
>>>>>> I just realised that there is also the argument that “global object
>>>>>> cannot get current context” and other limitations applied to whether a
>>>>>> theoretical “System/Module/Loader/Introspect” would be a global
>>>>>> module, or object, or keyword, or any (potentially context-sensitive)
>>>>>> combination of these.
>>>>>>
>>>>>> However, this all basically depends on what you specify in the
>>>>>> standard, doesn’t it? :)
>>>>>>
>>>>>> - Dynamic import has a “forbidden extensions” section[1] and how it
>>>>>> should work when it’s invoked as a CallExpression [2]
>>>>>> - import.meta has a full section describing how the runtime should
>>>>>> behave when encountering this particular property[3]
>>>>>> - new global objects like Reflect, Proxy, Symbol have specifications
>>>>>> on what they are and hoe they should be treated [4]
>>>>>>
>>>>>> A theoretical global object/keyword/identifier/special form X could
>>>>>> be specified as <object/keyword/identifier/avocado>. X.someProperty:
>>>>>> when encountered, let context be Ctx, let A be B, and C be B, populate 
>>>>>> with
>>>>>> properties from here and there and everywhere.
>>>>>>
>>>>>> Or look at the AwaitExpression[5]. There are specific limits in place
>>>>>> to guard where and how it’s used and when it is to be evaluated as
>>>>>> AwaitExpression.
>>>>>>
>>>>>> So there’s really *nothing* stopping you from designing a proper
>>>>>> System/Module/Loader/Introspect/Avocado or any subset thereof
>>>>>> instead of slapping “metaproperties” on everything in sight :)
>>>>>>
>>>>>> Like look. function.sent?? Really? And it’s extremely highly
>>>>>> context-specific: “function.sent can appear anywhere a YieldExpress would
>>>>>> be legal. Referencing function.sent outside of a GeneratorBody is a 
>>>>>> Syntax
>>>>>> Error.” [6]
>>>>>>
>>>>>> Look. Here’s a proposal: `Introspect.context.sent can appear anywhere
>>>>>> a YieldExpress would be legal. Referencing Introspect.context.sent 
>>>>>> outside
>>>>>> of a GeneratorBody is a Syntax Error.` And then you can use
>>>>>> `Introspect.context.target` instead of `new.target`.
>>>>>> `Introspect.context.module` instead of `import.meta`. Clean. Reasonable.
>>>>>> Extensible. Future-proof.
>>>>>>
>>>>>> [1] https://tc39.github.io/proposal-dynamic-import/#sec-forb
>>>>>> idden-extensions
>>>>>> [2] https://tc39.github.io/proposal-dynamic-import/#sec-import-calls
>>>>>> [3] https://tc39.github.io/proposal-import-meta/#sec-source-
>>>>>> text-module-records
>>>>>> [4] https://tc39.github.io/ecma262/#sec-reflection, https://
>>>>>> tc39.github.io/ecma262/#sec-proxy-objects, https://tc39.gith
>>>>>> ub.io/ecma262/#sec-symbol-objects
>>>>>> [5] https://tc39.github.io/ecma262/#prod-AwaitExpression
>>>>>> [6] https://github.com/allenwb/ESideas/blob/master/Generator
>>>>>> %20metaproperty.md
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, 05 Aug 2017 at 20:40 dmit...@dmitriid.com <
>>>>>> dmit...@dmitriid.com> wrote:
>>>>>>
>>>>>>> The problem with “metaproperties” is that they make the language
>>>>>>> more complex, chaotic and make it difficult to reason about the 
>>>>>>> language.
>>>>>>>
>>>>>>> See my previous post about the multitude of keyword and keyword-like
>>>>>>> types that the language has. It’s so bad that even “metaproperty” 
>>>>>>> concept
>>>>>>> itself isn’t defined in the standard except as a hardcoded `new.target` 
>>>>>>> [1]
>>>>>>>
>>>>>>> If you read, for example, through the import.meta draft, you see
>>>>>>> things ripe for inclusion in a proper API object.
>>>>>>>
>>>>>>> It gets even worse. Because “metaproperties” are not just attached
>>>>>>> to keywords. They are attached to keywords which have *fundamentally
>>>>>>> different semantics* in the language: `new` is an operator[2], it gets
>>>>>>> `new.target`. A function is a callable object [3], and it gets a
>>>>>>> `function.sent`. Import is … I don’t know what import is [4]. It gets
>>>>>>> transformed into a separate, made-just-for-import  CallExpression[5] and
>>>>>>> then it gets an `import.meta` on top of that [6] (as a hardcoded
>>>>>>> “metaproperty").
>>>>>>>
>>>>>>> Don’t forget that `super` gets its own properties. Since there’s no
>>>>>>> specification of what “metaproperties” are, they are just called
>>>>>>> superproperties[7] in the grammar. Because reasons.
>>>>>>>
>>>>>>> All this is chaos from the perspective of developer experience. And
>>>>>>> truly looks like random ad-hoc solutions to immediate problems with no
>>>>>>> long-term goals. Imagine how much better *and* future-proof it would be 
>>>>>>> if
>>>>>>> all this was in the form of a unified centralised API? There is a reason
>>>>>>> people laugh at PHP for its API and language design.
>>>>>>>
>>>>>>> [1] https://www.ecma-international.org/ecma-262/#sec-meta-properties
>>>>>>> [2] https://www.ecma-international.org/ecma-262/7.0/#sec-new
>>>>>>> -operator
>>>>>>> [3] https://www.ecma-international.org/ecma-262/7.0/#sec-ter
>>>>>>> ms-and-definitions-function
>>>>>>> [4] https://www.ecma-international.org/ecma-262/7.0/#sec-imports
>>>>>>> [5] https://tc39.github.io/proposal-dynamic-import/#sec-left
>>>>>>> -hand-side-expressions
>>>>>>> [6] https://tc39.github.io/proposal-import-meta/#sec-left-ha
>>>>>>> nd-side-expressions
>>>>>>> [7] https://www.ecma-international.org/ecma-262/7.0/#sec-lef
>>>>>>> t-hand-side-expressions
>>>>>>>
>>>>>>>
>>>>>>> On Sat, 05 Aug 2017 at 18:59 Matthew Robb <Matthew Robb
>>>>>>> <matthew+robb+%3cmatthewwr...@gmail.com%3E>> wrote:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> dmit...@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
>>>>>>>>>> <dmit...@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
>>>>>>>>> <dmit...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to