Re: Array.create and Function.create

[Matthew Robb]

Fwiw I'd absolutely love a way to create function objects that inherit from
an existing custom object.

On Thu, Jan 10, 2019, 2:13 PM Sultan  >what're the benefits over a object indexed by numbers `const o =
> Object.create(null); o[0] = 12; ...`?
>
> Better "optimisable" heuristics in a similar vain to `TypedArrays`. Most
> engines have perf cliffs with indexed objects after a certain threshold,
>
> Memory: at some point indexed objects have to grow by some factor(* N of
> the current size) until it reaches and exceeds your desired size resulting
> in more memory use that you bargained for or at some point the engine could
> downgrade it to dictionary-mode for any one reason.
>
> It is a fickle round to cross when you want predictable throughput
> performance, TypedArrays afford this, but they are not generic(support any
> value).
>
> >About the other function proposal (`Function.create`) I don't see any
> benefits in day to day use having a function without prototype
>
> Both the Array.create and Function.create are not meant as day-to-day
> data-structures.
> They are meant as low-level building blocks for abstraction that might be
> used on a day-to-day, abstractions that wish to guarantee better
> predictable performance.
>
> >and there'd be no way to get the length or iterate over it if you did.
>
> You don't need a length property to iterate the array if you own and
> manage the data-strucure:
>
> Exhibit A:
> var len = 10
> var arr = Array.create(null, len)
> for (var i = 0; i < len; i++) arr[i]
>
> Exhibit B: (tuple)
>
> var arr = Array.create(null, 2)
> arr[0] = 'a'
> arr[1] = 'b'
> return a
>
> In both examples you don't need a length property to access/visit all the
> elements in the array given they are both statically known at creation time.
>
>
> On Fri, Jan 11, 2019 at 12:20 AM Jordan Harband  wrote:
>
>> Sorry if I was unclear; it's *impossible* to have an array without a
>> `.length` own property, and there'd be no way to get the length or iterate
>> over it if you did. I'm also not clear on why you'd want to store named
>> properties on an array, especially if you can't iterate it because it
>> doesn't have a length?
>>
>> On Thu, Jan 10, 2019 at 11:04 AM T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>>> On Thu, Jan 10, 2019 at 1:54 PM Augusto Moura
>>>  wrote:
>>> >
>>> > If you don't want the iterable features neither the own properties,
>>> > what're the benefits over a object indexed by numbers `const o =
>>> > Object.create(null); o[0] = 12; ...`?
>>>
>>> Exactly.
>>>
>>> And re functions, using them as state containers without their usual
>>> features seems like a bad idea^H^H^H^H^H^H^H^H edge case best handled
>>> by `setPrototypeOf` and `delete`. :-)
>>>
>>> -- 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function Overloading or Pattern Matching of functions in Ecma

[Matthew Robb]

Perhaps the following form could eventually make sense for pattern matching
in function declarations:

```js
function sum_list(input, result = 0) case (input) {
when [head, ...tail] -> {
return sum_list(input, result + head);
},
when _ -> { return result; }
}
```

- Matthew Robb


On Mon, Oct 22, 2018 at 8:48 AM Isiah Meadows 
wrote:

> As mentioned previously, the pattern matching proposal does a lot to help
> here:
>
> ```js
> function sum_list(input, result = 0) {
> case (input) {
> when [head, ...tail] -> return sum_list(input, result + head),
> when _ -> return result,
> };
> }
> ```
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu 
> wrote:
> >
> > Hi Kai Zhu,
> >
> > I agree with you the new proposition should be of value to a web
> developer in daily work. If we observe the pattern it more closely
> resembles a more declarative form of solution implementation which is easy
> to code and understand. For example lets consider below piece of code:
> > ```js
> > function sum_list(input, result){
> > if(!input.length)
> > return result;
> > [head, ...input] = input;
> > return sum_list(input, result + head);
> > }
> > ```
> > Now the same code in the new proposal form
> >
> > ```js
> > function sum_list([head, ...tail], result){
> > result = result + head;
> > return sum_list(tail, result);
> > }
> >
> > function sum_list([], result){
> > return result;
> > }
> > ```
> >
> > This declarative model of coding also forces an immutable form of state
> management allowing for removing a family of bugs.
> >
> > Thanks & Regards,
> > Bishwendu.
> >
> > On Wed, Oct 17, 2018 at 12:57 PM kai zhu  wrote:
> >>
> >> hi Bishwendu, javascript is first-and-foremost a tool designed for
> web-product-development, a growing field that has eclipsed low-level
> general-purpose programming (where jobs are harder and harder to find) in
> the IT industry.
> >>
> >> you need to give compelling reasons (for such significant
> language-change) why i, a web-developer would benefit from from having
> overloaded-functions in my (mostly expendable-code) web-projects, as
> opposed to creating confusion and maintennance-headaches, when i typically
> have to rewrite code multiple-times during the web-integration process.
> >>
> >> kai zhu
> >> kaizhu...@gmail.com
> >>
> >>
> >>
> >> On 17 Oct 2018, at 12:23 PM, bishwendu kundu 
> wrote:
> >>
> >> Hello All,
> >>
> >> I have been a great fan of the evolution of JavaScript in the recent
> past. The language is steadily closing the gap to ideal functional
> paradigm. One of the things that I have liked the most about languages like
> Erlang/Elixir/Haskell is their ability to define functions with same name
> and different airty. The decision of invoking the correct function-argument
> pattern is dependent on the invocation of the function. Implicit pattern
> matching in aforementioned languages helps avoid costly cognitive loads
> introduced by explicit if/else based pattern of logic flow branching.
> >>
> >> The greatest power of the pattern matching which amazed me was,
> dropping the whole of looping construct, altogether. Elixir/Erlang have no
> LOOPS. Stack based recursive calls combined with JavaScript's closures
> suddenly strikes me as a very powerful programming model that not only
> increases readability of code but also promotes immutability of the data
> structures in use. The loops would continue to exist but more modern codes
> can be written leveraging the recursive model of JavaScript.
> >>
> >> With de-structuring of arrays & objects already in place in JavaScript,
> pattern-matching of functions can fit right in perfectly, thereby taking
> JavaScript another step closer to ideal functional programming model.
> >>
> >> Looking forward to your response.
> >>
> >> Thanks & Regards,
> >> Bishwendu.
> >> ___
> >> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[Matthew Robb]

There is practically no gain to suggest this syntax for arrows anyway as a
module has no this binding you are creating a perpetually contextless
function whereas using this shorthand syntax for a normal function makes
some sense. You lose implicit return regardless.


- Matthew Robb

On Tue, Oct 24, 2017 at 1:47 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > functions are already outmoded
>
> I don't know where you come from but to me:
>
> ```js
> // this ain't outmoded at all
> const obj = {
>   method() { return this === obj; }
> };
>
> // this ain't outmoded at all
> class Any {
>   method() { return this instanceof Any; }
> }
> ```
>
> And a module that provides mixins is definitively not outmoded at all
> ```js
> export method() {
>   return this !== undefined;
> };
> ```
>
> Omitting the arrow is everything but a syntax win here.
>
> Regards
>
>
>
>
> On Tue, Oct 24, 2017 at 2:32 PM, Brian Blakely <anewpage.me...@gmail.com>
> wrote:
>
>> At current, sans an explicit assignment, the pragma `foo() {...}` should
>> throw.
>>
>> On Tue, Oct 24, 2017 at 1:26 PM, dante federici <
>> c.dante.feder...@gmail.com> wrote:
>>
>>> Another annoying thing JS has to deal with is:
>>> ```
>>> // implicitly 'var'
>>> someVar = 10;
>>> ```
>>>
>>> So, something like:
>>> ```
>>> myFn() {
>>> }
>>> ```
>>>
>>> Would be considered as:
>>> ```
>>> var myFn = function() {
>>> }
>>> ```
>>>
>>> with what semantics exist now. Not best practices, but what is currently
>>> interpreted in the language.
>>>
>>> I'd 100% agree that, as a shorthand, this is nice:
>>> ```
>>> myFn() { }
>>> const myFn = () => {}
>>> ```
>>>
>>> Which is what I mean. But I'm not the full implementation of JavaScript.
>>>
>>> ___
>>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Consider date formatting

[Matthew Robb]

+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add
sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably
be a browser spec as the biggest motivation is going to be localization
which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <
michael.krie...@actifsource.com> wrote:

> Quoting my initial posting:
>
> > I know there are libraries for that, but I think it is fundamental
> enough to put it into the standard instead.
>
> Isn't it legitimate to ask for a defacto-standard to become a real
> standard...
>
> On 21.09.2017 09:13, Bob Myers wrote:
>
> There are third-party libraries which are so widely-used as to be defacto
> standards.
> Bob
>
> On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
>> I would like to suggest to take up date formatting into the standard.
>> Either as optional format parameter on Date.prototype.toDateString() or as
>> a separate method Date.prototype.toFormattedDateString(format).
>>
>> format should be a string in the form as specified in
>> https://tc39.github.io/ecma262/#sec-date-time-string-format
>>
>> I know there are libraries for that, but I think it is fundamental enough
>> to put it into the standard instead.
>>
>> I hope this was not already discussed before and I just did not find the
>> thread.
>>
>> --
>> Michael Kriegel • Head of R • Actifsource AG • Haldenstrasse 1 •
>> CH-6340 Baar • www.actifsource.com • +41 56 250 40 02
>> <+41%2056%20250%2040%2002>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> --
> Michael Kriegel • Head of R • Actifsource AG • Haldenstrasse 1 • CH-6340 
> Baar • www.actifsource.com • +41 56 250 40 02 <+41%2056%20250%2040%2002>
>
>
> ___
> 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

Re: Re: Make comma at the end of line optional

[Matthew Robb]

Okay what would be the cons to allowing semi colons in place of commas in
object literals?

I have an aversion to dangling commas. They're like,

On Sep 12, 2017 7:40 PM, "Jordan Harband"  wrote:

> I would take commas over a mixture a thousand times over; I'd do the same
> with semicolons - it's not the presence or absence of these tokens that
> causes a problem, it's the ambiguity.
>
> Introducing the same horrific ambiguity around semicolons, for commas,
> does not sound like a good idea.
>
> On Tue, Sep 12, 2017 at 1:57 PM, Tab Atkins Jr. 
> wrote:
>
>> On Tue, Sep 12, 2017 at 1:49 PM, Алексей  wrote:
>> > Think of it from a different way: if there would be no ',' how would you
>> > react on the idea of adding it? Peaty sour every one would decide that
>> would
>> > be a complete nonsense.
>>
>> This sort of hypothetical isn't useful; you're not proposing switching
>> over to *solely* comma-less, you're proposing a *mixture* of comma and
>> comma-less being allowed.  That has very different ergonomics than
>> either all-comma or all-comma-less.
>>
>> The hypothetical comma-less language would also have made many
>> different syntax decisions over the years to accommodate that, which
>> current JS has *not* made.  This causes the sorts of problems that
>> Claude/etc have pointed out.
>>
>> ~TJ
>> ___
>> 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

Re: Lazy evaluation

[Matthew Robb]

I think it would be nice to be able to define an own data property on an
object that while defined delegated up the prototype chain. This would
allow a getter in the proto to lazily assign to the own property without
triggering the property setter. This is even more nice when combined with
super as you could conceivably hit the setter which itself could assign to
the own property of the current instance.

Is that all too complicated? It seems perfect if only a little complicated.

On Sep 12, 2017 5:39 PM, "Steve Fink" <sph...@gmail.com> wrote:

> My intent was only to respond to the performance analysis, specifically
> the implication that the only performance cost is in building the new
> hidden class. That is not the case; everything that touches those objects
> is affected as well.
>
> Whether or not it's still the right way to accomplish what you're after, I
> wasn't venturing an opinion. I could probably come up with a benchmark
> showing that your WeakMap approach can be faster -- eg by only accessing
> the property once, but feeding the old and new versions of the object into
> code that executes many many many times (doing something that never looks
> at that property, but is now slightly slower because it isn't monomorphic).
> But I suspect that for practical usage, redefining the property *is* faster
> than a WeakMap.
>
> If I were to look beyond for other solutions for your problem, then I'm
> just speculating. Can decorators populate multiple properties once the
> expensive work is done?
>
> I really want to tell the VM what's going on. I guess if it knew that
> accessing a getter property would convert it into a value property, and
> that it was doing something that would access the getter, then it could
> know to use the outgoing shape instead of the incoming shape. If only it
> knew that the getter was pure... but that way lies madness.
>
> Given that most code that would slow down would also trigger the lazy
> defineProperty(), it's really not going to be that much of an issue. Any
> access after the first will see a single shape.
>
> meh. Just take the perf hit, with awareness that you may be triggering
> slight slowdowns in all users of that object. Or you might not. I doubt
> it'll be that big, since you'll probably just end up with an inline cache
> for both shapes and there won't be all that much to optimize based on
> knowing a single shape.
>
> Oh, and I think I was wrong about property enumeration order. The
> properties already existed, so defineProperty shouldn't modify the order
> IIUC. (I am awful with language semantics.)
>
> On 9/11/17 2:48 PM, Andrea Giammarchi wrote:
>
> Steve it's not solved in any other way. Even if you use a WeakMap with an
> object, you gonna lazy attach properties to that object.
>
> I honestly would like to see alternatives, if any, 'cause so far there is
> a benchmark and it proves already lazy property assignment is around 4x
> faster.
>
> So, it's easy to say "it's not the best approach" but apparently hard to
> prove that's the case?
>
> Looking forward to see better alternatives.
>
>
> On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink <sph...@gmail.com> wrote:
>
>> On 9/11/17 5:36 AM, Matthew Robb wrote:
>>
>> > I think it's irrelevant if internally VMs are not too happy. VMs are
>> there to solve our problems, not vice-versa ;-)
>> ​
>> This ^​ is very important for everyone to get on board with. Regardless
>> the cost should be negligible as the shape is only changing at the point of
>> delayed init. This will cause, for example V8, to deop the object and have
>> to build a new hidden class but only the one time. I guess it would
>> potentially be interesting to support an own property that when undefined
>> would delegate up the proto chain.
>>
>>
>> (I don't know, but) I would expect it to be worse than this. The shape is
>> changing at the point of delayed init, which means that if an engine is
>> associating the possible set of shapes with the constructor (or some other
>> form of allocation site + mandatory initialization), then that site will
>> produce multiple shapes. All code using such objects, if they ever see both
>> shapes, will have to handle them both. Even worse, if you have several of
>> these delayed init properties and you end up lazily initializing them in
>> different orders (which seems relatively easy to do), then the internal
>> slot offsets will vary.
>>
>> You don't need to bend over backwards to make things easy for the VMs,
>> but you don't want to be mean to them either. :-)
>>
>> Not to mention that the observable property iteration order will vary.
>>
&

Re: Re: Lazy evaluation

[Matthew Robb]

> I think it's irrelevant if internally VMs are not too happy. VMs are
there to solve our problems, not vice-versa ;-)
​
This ^​ is very important for everyone to get on board with. Regardless the
cost should be negligible as the shape is only changing at the point of
delayed init. This will cause, for example V8, to deop the object and have
to build a new hidden class but only the one time. I guess it would
potentially be interesting to support an own property that when undefined
would delegate up the proto chain.


- Matthew Robb

On Mon, Sep 11, 2017 at 7:09 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Hi Peter.
>
> Unless you have a faster way to do lazy property assignment, I think it's
> irrelevant if internally VMs are not too happy. VMs are there to solve our
> problems, not vice-versa ;-)
>
> Regards
>
>
>
> On Mon, Sep 11, 2017 at 11:54 AM, peter miller <fuchsia.gr...@virgin.net>
> wrote:
>
>> Hi Andrea,
>>
>> ```
>>> class CaseLazy {
>>>   get bar() {
>>> var value = Math.random();
>>> Object.defineProperty(this, 'bar', {value});
>>> return value;
>>>   }
>>> }
>>> ```
>>>
>>
>> Doesn't this count as redefining the shape of the object? Or are the
>> compilers fine with it?
>>
>> Peter
>> --
>> "There were drawings, and sheets of paper with writing on them, and it
>> seemed that they were the sustenance of life, that here were the warlocks,
>> almost the vehicles of destruction of man's life, but at the same time the
>> very reason for his living." --- Maeve Gilmore/Titus Awakes.
>>
>
>
> ___
> 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

State of Decorators

[Matthew Robb]

Hello all!

Today it struck me that the usefulness and prevalence of Decorators in my
React applications has been actively climbing and this feels to be at odds
with the rate of progression within the committee. To me it is quickly
rising as the most influential feature to the way I write code. At the end
of the day my code is considerably cleaner, more declarative, and more
composable.

I am curious as to why this feature is not one of the top discussed or
actively developed proposals in the pipeline? In the current form it's
already proving to be so useful and would be more so if it were supported
in more places (e.g. on functions or plain object properties).

Any insight into this would be great, thank you!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native Proxy Syntax

[Matthew Robb]

I feel like this would be easier handled as a subclass helper:
```
f
​unction asProxy(traps={}, Class=function asProxy(){}) {
  return class extends Class {
constructor() {
   super(...arguments);
   return new Proxy(this, traps);
}
  }
}​

class MyClass extends asProxy({ ... }) { ... }

class MyOtherClass extends asProxy({ ... }, MyClass) { ... }
```


- Matthew Robb

On Wed, Aug 23, 2017 at 11:08 AM, Vihan Bhargava <cont...@vihan.org> wrote:

> The `Proxy` class is great for classes however at the moment, the current
> syntax can be unwieldy:
>
> ```
> class MyClass {
>constructor() {
>return new Proxy(this, {
>get: function(target, name) {
>if (name in target) return target[name];
>// ... do something to determine property
>}
>});
>}
> }
> ```
>
> My proposal is to introduce a more idiomatic syntax for proxies in classes:
>
> ```
> class MyClass {
>constructor () { ... }
>get *(name) {
>// ... do something to determine property
>}
> }
> ```
>
> This already is much more clear than the above.
> ___
> 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

Re: Re: Defer expression

[Matthew Robb]

Yeah essentially although I'd think of it more as sugar for:

(async () => { await null; ... })()

On Aug 17, 2017 4:17 PM, "Tab Atkins Jr." <jackalm...@gmail.com> wrote:

> On Thu, Aug 17, 2017 at 12:12 PM, Matthew Robb <matthewwr...@gmail.com>
> wrote:
> > Honestly have there been any proposals for something like `do async { //
> can
> > await here  }` which would produce a promise in the enclosing scope
>
> Do-expressions haven't advanced in general yet, but if/when they do,
> this seems like it might be reasonable. It's just sugar for the
> `Promise.resolve().then(()=>{...})` expression, right?
>
> ~TJ
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Defer expression

[Matthew Robb]

Honestly have there been any proposals for something like `do async { //
can await here  }` which would produce a promise in the enclosing scope


- Matthew Robb

On Thu, Aug 17, 2017 at 11:27 AM, Logan Smyth <loganfsm...@gmail.com> wrote:

> `setTimeout` it is defined in the HTML spec, https://www.w3.org/TR/html5/
> single-page.html#timers, not the ECMA spec. The ECMA spec has no concept
> of time-based delays at all, promise-based or otherwise.
>
> On Wed, Aug 16, 2017 at 11:03 PM, Naveen Chawla <naveen.c...@gmail.com>
> wrote:
>
>> An in built `Promise` version of `setTimeout` would be cool:
>> `Promise.delay()` and `Promise.delay(500)`
>>
>> On Thu, 17 Aug 2017, 7:37 a.m. kai zhu <kaizhu...@gmail.com> wrote:
>>
>>> setTimeout is still the best solution in my mind.  none of the promise
>>> or async code examples presented are as immediately obvious as
>>> setTimeout that the code is to self-run at a later time (and you don't
>>> need the 1ms argument).
>>>
>>> ```js
>>> // self-comment that this code will self-run
>>> // after the main script in a reasonably immediate fashion
>>> setTimeout(function () {
>>> // deferred code
>>> })
>>> ```
>>>
>>>
>>>
>>>
>>> On 8/17/17, Matthew Robb <matthewwr...@gmail.com> wrote:
>>> > I think this will actually get you what you're after:
>>> >
>>> > (async function () {
>>> >
>>> > await null;
>>> > // Deferred code here
>>> >
>>> > })()
>>> >
>>> >
>>> > On Aug 16, 2017 5:46 PM, "Darien Valentine" <valentin...@gmail.com>
>>> wrote:
>>> >
>>> > @logan ah, oops, that was an (incorrect) assumption about the proposed
>>> > behavior on my part
>>> >
>>> > ___
>>> > 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
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Defer expression

[Matthew Robb]

I think this will actually get you what you're after:

(async function () {

await null;
// Deferred code here

})()


On Aug 16, 2017 5:46 PM, "Darien Valentine"  wrote:

@logan ah, oops, that was an (incorrect) assumption about the proposed
behavior on my part

___
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

Re: import.meta and TC39 process as a whole

[Matthew Robb]

 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 . 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 p

Re: 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 <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

Re: import.meta and TC39 process as a whole

[Matthew Robb]

Yes super is a keyword and had been reserved for a long time. I don't
necessarily disagree with your premise about introducing new keywords that
aren't reserved but the current tc39 policy on this is to not due to the
high likelihood that it breaks current user code.

This conversation could go very different if that policy were amended and
if you think you have a way to do this that doesn't break existing user
code I would suggest submitting that as a proposal.

On Aug 5, 2017 12: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?)
>
>
>
>
> On Sat, 05 Aug 2017 at 18:03 Matthew Robb  <matthew+robb+%3cmatthewwr...@gmail.com%3E>> wrote:
>
>> Ah but you can do:
>>
>> export function meta(key) {
>> return import.meta[key]:
>> }
>>
>> On Aug 5, 2017 11:59 AM, "Dmitrii Dimandt" <dmit...@dmitriid.com> wrote:
>>
>>> Import is already made to be a context-sensitive keyword
>>>
>>> I don’t think you can have a
>>>
>>> function x() {
>>>import {x} from ‘module’;
>>> }
>>>
>>>
>>>
>>> On Sat, 05 Aug 2017 at 13:07 "T.J. Crowder" <">"T.J. Crowder" > wrote:
>>>
>>>> On Sat, Aug 5, 2017 at 11:58 AM, Naveen Chawla
>>>> <naveen.c...@gmail.com> wrote:
>>>> >
>>>> > How is `document` and `window` handled when someone does
>>>> > `const document =` ?
>>>>
>>>> At global scope in a script body, in a browser context, it's an error,
>>>> as you presumably know, because `document` is already declared.
>>>>
>>>> > It would seem perfectly fine to allow `module` to be masked by
>>>> > other variables, and if someone wants to use the module-global
>>>> > `module`, they can just rename in order to get access.
>>>>
>>>> Yes. That's what I said.
>>>>
>>>> The issue with it being an identifier isn't shadowing. It's that then
>>>> it's a binding with a value, and that value can be passed around,
>>>> which I suspect isn't okay.
>>>>
>>>> For clarity: To get `module`, either:
>>>>
>>>> 1. It's a context-sensitive keyword, and code that's using it needs to
>>>> be updated when migrated to a module.
>>>>
>>>> 2. It's an identifier, which means its value can be passed around.
>>>>
>>>> All I've said, again, is: I *suspect* that having it be an identifier
>>>> is a non-starter. But perhaps you can get support for a
>>>> context-sensitive keyword, if people feel it's worth the complexity
>>>> for mildly-improved semantics.
>>>>
>>>> -- 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

Re: import.meta and TC39 process as a whole

[Matthew Robb]

Ah but you can do:

export function meta(key) {
return import.meta[key]:
}

On Aug 5, 2017 11:59 AM, "Dmitrii Dimandt"  wrote:

> Import is already made to be a context-sensitive keyword
>
> I don’t think you can have a
>
> function x() {
>import {x} from ‘module’;
> }
>
>
>
> On Sat, 05 Aug 2017 at 13:07 "T.J. Crowder" <">"T.J. Crowder" > wrote:
>
>> On Sat, Aug 5, 2017 at 11:58 AM, Naveen Chawla
>>  wrote:
>> >
>> > How is `document` and `window` handled when someone does
>> > `const document =` ?
>>
>> At global scope in a script body, in a browser context, it's an error,
>> as you presumably know, because `document` is already declared.
>>
>> > It would seem perfectly fine to allow `module` to be masked by
>> > other variables, and if someone wants to use the module-global
>> > `module`, they can just rename in order to get access.
>>
>> Yes. That's what I said.
>>
>> The issue with it being an identifier isn't shadowing. It's that then
>> it's a binding with a value, and that value can be passed around,
>> which I suspect isn't okay.
>>
>> For clarity: To get `module`, either:
>>
>> 1. It's a context-sensitive keyword, and code that's using it needs to
>> be updated when migrated to a module.
>>
>> 2. It's an identifier, which means its value can be passed around.
>>
>> All I've said, again, is: I *suspect* that having it be an identifier
>> is a non-starter. But perhaps you can get support for a
>> context-sensitive keyword, if people feel it's worth the complexity
>> for mildly-improved semantics.
>>
>> -- 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

Re: import.meta and TC39 process as a whole

[Matthew Robb]

Can anyone knowledgeable on the topic of direct vs indirect evaluation
chime in with an explanation or a link to one as my understanding is enough
to "get it" but not too really explain it.

On Aug 5, 2017 11:57 AM, "Dmitrii Dimandt"  wrote:

> Exactly! import.meta doesn’t make import an object. new.target doesn’t
> make new an object. function.sent doesn’t make function an object.
>
> These are just purely arbitrary things tacked on top of randomly selected
> keywords because at one point someone needed some *introspection* info
> (such as “current execution context” etc.). Instead of designing a proper
> introspection API (or even the beginnings of it), 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)
> - keywords that look like objects *and* functions but are neither (import)
>
> The last three are now the current fashionable trend in TC39 for some
> reason. Why?
>
>
> On Sat, 05 Aug 2017 at 15:40 "T.J. Crowder" <">"T.J. Crowder" > wrote:
>
>> On Sat, Aug 5, 2017 at 2:35 PM, Naveen Chawla 
>> wrote:
>> >
>> > Thanks for the link! That means that `import` is already on the
>> borderline of the spec since it wants to be a function and object.
>>
>> No, not at all. It's a keyword. `import.meta` doesn't make `import` an
>> object, any more than `new.target` makes `new` an object.
>>
>> -- 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

Re: import.meta and TC39 process as a whole

[Matthew Robb]

It all boils down to direct and indirect evaluation and static contextual
information. It can't be an identifier any more than super or this. It
can't be passed because it's a different type of evaluation that happens
relative to static context, in this case the containing module body.

You can pass access to it by closing over it however.

On Aug 5, 2017 11:47 AM, "Naveen Chawla"  wrote:

Yes although it could be implemented like an object & function underneath
even if it's not officially exposed as one.

I think the key question is for interested TC39 members - whether passing
it around must be expressly disallowed or allowed. If allowed, `module` is
the only choice that won't go against the existing advice against
identifiers being keywords (besides being a more suitable name anyway). If
it must be expressly disallowed, `import` would be the compromise choice.

A use-case for passing it somewhere might be to a static helper function
which lives in another module, and which might use the `meta` information,
and which carries out the import whose parameter is based on some logic
that is repeated throughout the app.

Reasons for disallowing this must come from TC39 - till then I'm stumped

On Sat, 5 Aug 2017 at 19:10 T.J. Crowder 
wrote:

> On Sat, Aug 5, 2017 at 2:35 PM, Naveen Chawla 
> wrote:
> >
> > Thanks for the link! That means that `import` is already on the
> borderline of the spec since it wants to be a function and object.
>
> No, not at all. It's a keyword. `import.meta` doesn't make `import` an
> object, any more than `new.target` makes `new` an object.
>
> -- 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

Re: import.meta and TC39 process as a whole

[Matthew Robb]

And here is the notes from progressing the proposal to stage 2:
https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/may-25.md#15iif-importmeta-for-stage-2


- Matthew Robb

On Fri, Aug 4, 2017 at 9:14 AM, Matthew Robb <matthewwr...@gmail.com> wrote:

> This seems to be the conclusion the lead to consensus:
> ```
> YK: Option #3.c (import { url } from here) is undesirable because it must
> be top-level.
>
> (bikeshed discussion of what to call import.thing) (general consensus for
> import.meta)
>
> MM: What about exposing dynamic import() as a method of import.meta?
>
> DH: import.meta.import() is just really verbose for a common idiom.
>
> BF: And import() should be available in script, where the import.meta
> meta-property is not available.
>
> Conclusion/Resolution
>
> Let's go with import.meta; Domenic to come back later this meeting with a
> proposal
> ```
>
>
> - Matthew Robb
>
> On Fri, Aug 4, 2017 at 9:11 AM, Matthew Robb <matthewwr...@gmail.com>
> wrote:
>
>> Just want to add some links to this convo:
>>
>> https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/m
>> ay-23.md#16iib-module-import-options-discussion-potentially-for-stage-1
>> https://docs.google.com/presentation/d/1p1BGFY05-iCiop8yV0hN
>> yWU41_wlwwfv6HIDkRNNIBQ/edit?usp=sharing
>>
>>
>> - Matthew Robb
>>
>> On Fri, Aug 4, 2017 at 9:08 AM, Dmitrii Dimandt <dmit...@dmitriid.com>
>> wrote:
>>
>>> import.meta isn’t rushed. yet. dynamic imports? definitely rushed.
>>> That’s the only reason import.meta exists in the first place. (Much like
>>> function.sent, new.target and many other things).
>>>
>>> Ad-hoc shortsighted solutions lead to ad-hoc shortsighted solutions.
>>> Worse still, these solutions have actually been defended by other equally
>>> bad solutions!
>>>
>>> dynamic import’s looks-like-function-doesn’t-look-like-function was
>>> defended by invoking things like !function{}() [1]. import.meta is defended
>>> by pointing at new.target (link lost in my memory) etc. Basically these
>>> features just open a huge can of worms that will keep spreading
>>> uncontrollably throughout the language. It’s already happening and we are
>>> already witness to this.
>>>
>>> [1] https://github.com/tc39/proposal-dynamic-import/issues/3
>>> 5#issuecomment-274561995
>>>
>>> P.S. regarding polluting `import`, this proposal for node actually takes
>>> this into consideration: https://github.com/WebReflection/node-eps/blo
>>> b/master/XXX-module-import.md#why-polluting-module-and-not-require-
>>>
>>> On Fri, 04 Aug 2017 at 14:54 Matthew Robb >> <matthew+robb+%3cmatthewwr...@gmail.com%3E>> wrote:
>>>
>>>> I don't want to fan a fire and personally I've preferred other solution
>>>> s for module meta data but nothing is being rushed imo. I've been closely
>>>> tracking this discussion in tc39 for some years and while again some of the
>>>> current front runners are not my favorite proposals they are well thought
>>>> out, well intended, and painstakingly deliberated.
>>>>
>>>> Now is the time to raise objections but please it helps no one's cause
>>>> to come at this with anything but constructive discourse. You have validity
>>>> in your objections but it's going to be difficult to Garner support without
>>>> tact.
>>>>
>>>> On Aug 4, 2017 8:45 AM, "Dmitrii Dimandt" <dmit...@dmitriid.com> wrote:
>>>>
>>>>> Sorry, it’s just the manner in which Javascript is being actively
>>>>> demolished has really irked me. Especially the speed with which these
>>>>> decisions are carried out. Suggestions like “you should really do some
>>>>> light reading before engaging in arguments” don’t help either.
>>>>>
>>>>> These are decisions we as developers have to live with for years to
>>>>> come. It’s very easy to add features to a language. It’s almost impossible
>>>>> to remove them. Hence the (uncalled for) curtness.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 04 Aug 2017 at 14:31 James M Snell >>>> <james+m+snell+%3cjasn...@gmail.com%3E>> wrote:
>>>>>
>>>>>> Dmitrii,
>>>>>>
>>>>>> Quick aside: the rude manner in which you are communicating is
>>>>>> interfering with your goal of convincing anyone. Perhaps if yo

Re: import.meta and TC39 process as a whole

[Matthew Robb]

This seems to be the conclusion the lead to consensus:
```
YK: Option #3.c (import { url } from here) is undesirable because it must
be top-level.

(bikeshed discussion of what to call import.thing) (general consensus for
import.meta)

MM: What about exposing dynamic import() as a method of import.meta?

DH: import.meta.import() is just really verbose for a common idiom.

BF: And import() should be available in script, where the import.meta
meta-property is not available.

Conclusion/Resolution

Let's go with import.meta; Domenic to come back later this meeting with a
proposal
```


- Matthew Robb

On Fri, Aug 4, 2017 at 9:11 AM, Matthew Robb <matthewwr...@gmail.com> wrote:

> Just want to add some links to this convo:
>
> https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/
> may-23.md#16iib-module-import-options-discussion-potentially-for-stage-1
> https://docs.google.com/presentation/d/1p1BGFY05-iCiop8yV0hNyWU41_
> wlwwfv6HIDkRNNIBQ/edit?usp=sharing
>
>
> - Matthew Robb
>
> On Fri, Aug 4, 2017 at 9:08 AM, Dmitrii Dimandt <dmit...@dmitriid.com>
> wrote:
>
>> import.meta isn’t rushed. yet. dynamic imports? definitely rushed. That’s
>> the only reason import.meta exists in the first place. (Much like
>> function.sent, new.target and many other things).
>>
>> Ad-hoc shortsighted solutions lead to ad-hoc shortsighted solutions.
>> Worse still, these solutions have actually been defended by other equally
>> bad solutions!
>>
>> dynamic import’s looks-like-function-doesn’t-look-like-function was
>> defended by invoking things like !function{}() [1]. import.meta is defended
>> by pointing at new.target (link lost in my memory) etc. Basically these
>> features just open a huge can of worms that will keep spreading
>> uncontrollably throughout the language. It’s already happening and we are
>> already witness to this.
>>
>> [1] https://github.com/tc39/proposal-dynamic-import/issues/
>> 35#issuecomment-274561995
>>
>> P.S. regarding polluting `import`, this proposal for node actually takes
>> this into consideration: https://github.com/WebReflection/node-eps/blo
>> b/master/XXX-module-import.md#why-polluting-module-and-not-require-
>>
>> On Fri, 04 Aug 2017 at 14:54 Matthew Robb > <matthew+robb+%3cmatthewwr...@gmail.com%3E>> wrote:
>>
>>> I don't want to fan a fire and personally I've preferred other solution
>>> s for module meta data but nothing is being rushed imo. I've been closely
>>> tracking this discussion in tc39 for some years and while again some of the
>>> current front runners are not my favorite proposals they are well thought
>>> out, well intended, and painstakingly deliberated.
>>>
>>> Now is the time to raise objections but please it helps no one's cause
>>> to come at this with anything but constructive discourse. You have validity
>>> in your objections but it's going to be difficult to Garner support without
>>> tact.
>>>
>>> On Aug 4, 2017 8:45 AM, "Dmitrii Dimandt" <dmit...@dmitriid.com> wrote:
>>>
>>>> Sorry, it’s just the manner in which Javascript is being actively
>>>> demolished has really irked me. Especially the speed with which these
>>>> decisions are carried out. Suggestions like “you should really do some
>>>> light reading before engaging in arguments” don’t help either.
>>>>
>>>> These are decisions we as developers have to live with for years to
>>>> come. It’s very easy to add features to a language. It’s almost impossible
>>>> to remove them. Hence the (uncalled for) curtness.
>>>>
>>>>
>>>>
>>>> On Fri, 04 Aug 2017 at 14:31 James M Snell >>> <james+m+snell+%3cjasn...@gmail.com%3E>> wrote:
>>>>
>>>>> Dmitrii,
>>>>>
>>>>> Quick aside: the rude manner in which you are communicating is
>>>>> interfering with your goal of convincing anyone. Perhaps if you tried not
>>>>> being so rude, people here would be more willing to listen to what you're
>>>>> saying.
>>>>>
>>>>> - James
>>>>>
>>>>> On Fri, Aug 4, 2017 at 1:09 AM Dmitrii Dimandt <dmit...@dmitriid.com>
>>>>> wrote:
>>>>>
>>>>>> Let’s continue with the trend of light reading. Let’s see the
>>>>>> multitude of things that are in JS, and no one bats an eye:
>>>>>>
>>>>>> — start quote —
>>>>>>
>>>>>> Note that imple

Re: import.meta and TC39 process as a whole

[Matthew Robb]

Just want to add some links to this convo:

https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/may-23.md#16iib-module-import-options-discussion-potentially-for-stage-1
https://docs.google.com/presentation/d/1p1BGFY05-iCiop8yV0hNyWU41_wlwwfv6HIDkRNNIBQ/edit?usp=sharing


- Matthew Robb

On Fri, Aug 4, 2017 at 9:08 AM, Dmitrii Dimandt <dmit...@dmitriid.com>
wrote:

> import.meta isn’t rushed. yet. dynamic imports? definitely rushed. That’s
> the only reason import.meta exists in the first place. (Much like
> function.sent, new.target and many other things).
>
> Ad-hoc shortsighted solutions lead to ad-hoc shortsighted solutions. Worse
> still, these solutions have actually been defended by other equally bad
> solutions!
>
> dynamic import’s looks-like-function-doesn’t-look-like-function was
> defended by invoking things like !function{}() [1]. import.meta is defended
> by pointing at new.target (link lost in my memory) etc. Basically these
> features just open a huge can of worms that will keep spreading
> uncontrollably throughout the language. It’s already happening and we are
> already witness to this.
>
> [1] https://github.com/tc39/proposal-dynamic-import/
> issues/35#issuecomment-274561995
>
> P.S. regarding polluting `import`, this proposal for node actually takes
> this into consideration: https://github.com/WebReflection/node-eps/
> blob/master/XXX-module-import.md#why-polluting-module-and-not-require-
>
> On Fri, 04 Aug 2017 at 14:54 Matthew Robb  <matthew+robb+%3cmatthewwr...@gmail.com%3E>> wrote:
>
>> I don't want to fan a fire and personally I've preferred other solution s
>> for module meta data but nothing is being rushed imo. I've been closely
>> tracking this discussion in tc39 for some years and while again some of the
>> current front runners are not my favorite proposals they are well thought
>> out, well intended, and painstakingly deliberated.
>>
>> Now is the time to raise objections but please it helps no one's cause to
>> come at this with anything but constructive discourse. You have validity in
>> your objections but it's going to be difficult to Garner support without
>> tact.
>>
>> On Aug 4, 2017 8:45 AM, "Dmitrii Dimandt" <dmit...@dmitriid.com> wrote:
>>
>>> Sorry, it’s just the manner in which Javascript is being actively
>>> demolished has really irked me. Especially the speed with which these
>>> decisions are carried out. Suggestions like “you should really do some
>>> light reading before engaging in arguments” don’t help either.
>>>
>>> These are decisions we as developers have to live with for years to
>>> come. It’s very easy to add features to a language. It’s almost impossible
>>> to remove them. Hence the (uncalled for) curtness.
>>>
>>>
>>>
>>> On Fri, 04 Aug 2017 at 14:31 James M Snell >> <james+m+snell+%3cjasn...@gmail.com%3E>> wrote:
>>>
>>>> Dmitrii,
>>>>
>>>> Quick aside: the rude manner in which you are communicating is
>>>> interfering with your goal of convincing anyone. Perhaps if you tried not
>>>> being so rude, people here would be more willing to listen to what you're
>>>> saying.
>>>>
>>>> - James
>>>>
>>>> On Fri, Aug 4, 2017 at 1:09 AM Dmitrii Dimandt <dmit...@dmitriid.com>
>>>> wrote:
>>>>
>>>>> Let’s continue with the trend of light reading. Let’s see the
>>>>> multitude of things that are in JS, and no one bats an eye:
>>>>>
>>>>> — start quote —
>>>>>
>>>>> Note that implements, let, private, public, interface, package, p
>>>>> rotected, static, and yield are disallowed in strict mode only.
>>>>>
>>>>> You may have noticed I included eval and arguments in the list. These
>>>>> are not strictly reserved words, but they sure act like them
>>>>> <http://ecma-international.org/ecma-262/5.1/#sec-12.2.1> — they’re
>>>>> disallowed in strict mode too.
>>>>>
>>>>> Also, the (unlisted) NaN, Infinity, and undefined properties of the
>>>>> global object are immutable or read-only properties in ES5. So even 
>>>>> though var
>>>>> NaN = 42; in the global scope wouldn’t throw an error, it wouldn’t
>>>>> actually do anything. To avoid confusion, I’d suggest avoiding the use of
>>>>> these identifiers altogether, even though they’re not strictly reserved
>>>>> words.
>>>>>
&g

Re: import.meta and TC39 process as a whole

[Matthew Robb]

I'd like to refocus this thread myself. I have to dig around for the
meeting notes where it was decided that import.meta should proceed over
`import meta` but I do remember there was no rationale other than
consensus. Can some of you who physically attend those meetings provide a
real comparison and some of the whys for that consensus?

A different thread should be used to discuss:
- TC39 process
- keyword meta properties in general
- API centric reflection
- Module Loader features not related to module context specific meta data


- Matthew Robb

On Fri, Aug 4, 2017 at 3:20 AM, Dmitrii Dimandt <dmit...@dmitriid.com>
wrote:

> I’ll reply to several emails with one, so as not to spread more-or-less
> similar texts over multiple small emails.
>
> > whatwg/loader was too big of a spec. It was floated around in various
> forms for at least 5 years. Despite the very hard work of its champions it
> didn't garner enough implementer support.
>
> And the reason is: it was supposed to be a properly designed spec. That is
> why it was big. Because you either do it properly, or not at all
>
> > I think history has proven now that incremental improvements are more
> likely to succeed, so I'm happy to see import() and import.meta be able to
> go through the process at a relatively swift pace.
>
> No. These are not incremental improvements. These are ad-hoc solutions
> that beget more and more ad-hoc solutions. Calling it “incremental
> improvements” is putting slapstick on a pig.
>
> Let’s take dynamic imports as a prime example of a horrible no-good ad-hoc
> solution and how it begat a horrible no-good ad-hoc solution in the form of
> import.meta.
>
> import is a keyword. It’s scope and usage are known, simple, and
> understandable.
>
> What is import()? It looks like a function, it behaves like a function
> (it’s invoked like a function, it accepts parameters like a function, it
> returns values like a function). Except it’s not a function. In *some*
> contexts it is a function:
>
> import(‘blabla’).then(() => …)
>
> In *other* contexts it is not:
>
>[‘bla’, ‘bla’].map(import) and others
>
> To quote myself from an issue: "So, what is this new import? A new
> keyword? No. A builtin function on par with eval, parseInt et al? Why does
> it override the name of an existing keyword? Wouldn't it be better to
> introduce module-related functionality into a new global Module object
> exposing Module.import, Module.importAsync etc.?”
>
> Well, the only somewhat-valid argument for the dynamic import is this:
>
> > I suggest you to look at previous discussions about import, and why it
> is different (a hint: it is different because like super, it needs some
> contextual information).
>
> Let’s consider this:
>
> - super() is a *new* function-like keyword that doesn’t override behaviour
> of an existing one. It has its clearly defined place where it can be used,
> and, well, it is a function call as it ends up calling user-defined
> functions (etc. etc. etc., see https://github.com/tc39/
> proposal-dynamic-import/issues/23#issuecomment-263439543)
>
> - the argument for context is especially funny considering how import.meta
> started
>
> First of all, this is a language you design. There’s nothing stopping you
> from providing context to System.load. Or Loader.import, or…
>
> Second. Let’s see how import.meta proposal started (
> https://esdiscuss.org/notes/2017-05-23#16iiia-accessing-
> host-specific-module-metadata-from-inside-a-module):
>
>> Probably a good idea to do import * as module from "js:context"
>
> See? Since you scrapped proper implementation in favour of an ad-hoc
> solution eschewing common sense, now you scramble to find ad-hoc solutions
> to your ad-hoc solutions. Let’s just for a second assume you went with
> Module.import(). All of a sudden you’re free to extend Module with a
> Module.context or Module.meta, define it as Introspection API and have fun
> with it. Instead, you go for this (can’t find the link right now) in favour
> of import.meta:
>
>   > Yes, we have new.target, super.* and function.sent as precedent
>
> That is, you take horrible ad-hoc design decisions and present them as
> viable precedent.
>
> This morning literally in the span of time between stepping out of the
> shower and finishing my morning shave I came up with a solution that does
> away with new.target, function.sent and import.meta.
>
> It’s called System.context (especially useful with
> https://github.com/tc39/proposal-optional-chaining)
>
> System.context.function.{sent, target, what,have,you},
> System.context.module.{whatever,meta,info,you,might,want,to,slap,on}
>
> See. Suddenly you have an infi

Re: import.meta and TC39 process as a whole

[Matthew Robb]

I don't want to fan a fire and personally I've preferred other solution s
for module meta data but nothing is being rushed imo. I've been closely
tracking this discussion in tc39 for some years and while again some of the
current front runners are not my favorite proposals they are well thought
out, well intended, and painstakingly deliberated.

Now is the time to raise objections but please it helps no one's cause to
come at this with anything but constructive discourse. You have validity in
your objections but it's going to be difficult to Garner support without
tact.

On Aug 4, 2017 8:45 AM, "Dmitrii Dimandt"  wrote:

> Sorry, it’s just the manner in which Javascript is being actively
> demolished has really irked me. Especially the speed with which these
> decisions are carried out. Suggestions like “you should really do some
> light reading before engaging in arguments” don’t help either.
>
> These are decisions we as developers have to live with for years to come.
> It’s very easy to add features to a language. It’s almost impossible to
> remove them. Hence the (uncalled for) curtness.
>
>
>
> On Fri, 04 Aug 2017 at 14:31 James M Snell  > wrote:
>
>> Dmitrii,
>>
>> Quick aside: the rude manner in which you are communicating is
>> interfering with your goal of convincing anyone. Perhaps if you tried not
>> being so rude, people here would be more willing to listen to what you're
>> saying.
>>
>> - James
>>
>> On Fri, Aug 4, 2017 at 1:09 AM Dmitrii Dimandt 
>> wrote:
>>
>>> Let’s continue with the trend of light reading. Let’s see the multitude
>>> of things that are in JS, and no one bats an eye:
>>>
>>> — start quote —
>>>
>>> Note that implements, let, private, public, interface, package, p
>>> rotected, static, and yield are disallowed in strict mode only.
>>>
>>> You may have noticed I included eval and arguments in the list. These
>>> are not strictly reserved words, but they sure act like them
>>>  — they’re
>>> disallowed in strict mode too.
>>>
>>> Also, the (unlisted) NaN, Infinity, and undefined properties of the
>>> global object are immutable or read-only properties in ES5. So even though 
>>> var
>>> NaN = 42; in the global scope wouldn’t throw an error, it wouldn’t
>>> actually do anything. To avoid confusion, I’d suggest avoiding the use of
>>> these identifiers altogether, even though they’re not strictly reserved
>>> words.
>>>
>>> — end quote —
>>>
>>> Oh, hello. What do we have here? Non-reserved words like they are
>>> reserved, and JS treating them in a special way.
>>>
>>> So. The *only* reason *not* to introduce a proper global introspection
>>> API is?
>>>
>>> On Fri, 04 Aug 2017 at 10:03 dmit...@dmitriid.com 
>>> wrote:
>>>
 I’d recommend you assume your opponent has done some light reading. And
 I’d suggest you yourself read the links you post (that is, practice what
 you preach).

 Multiple reserved keywords have been both added to the language and
 removed from the language. Because *the language evolves*.

 However, you (and TC39 in general) keep insisting that
 short-sightedness and ad-hoc solutions is the only way forward for
 JavaScript.

 You don’t like System, you think it cannot be used? Oh, introduce an
 `introspect` keyword. Introduce a `system` keyword. Heck, nothing stopped
 you from introducing a language-level built-in in the form of Symbol,
 what’s stopping you now?



 On Fri, 04 Aug 2017 at 09:55 Jordan Harband >>> > wrote:

> Because it's been reserved syntax since JavaScript's inception, and
> System hasn't.
>
> I'd recommend some light reading before attempting to continue
> arguing: https://mathiasbynens.be/notes/reserved-keywords
>
> On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt  > wrote:
>
>> But you can’t `var x = import`, for example. I guess you can’t `var
>> import = {}`  either.
>>
>> Hmmm… I wonder why…
>>
>>
>>
>> On Fri, 04 Aug 2017 at 09:50 Jordan Harband > > wrote:
>>
>>> It can't be made syntax, because `var System = {};` is valid code,
>>> and we can't break the web. (seriously)
>>>
>>> On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <
>>> dmit...@dmitriid.com> wrote:
>>>
 Make “System” syntax, and there you go.

 Instead we have multiple ad-hoc random additions to random keywords
 just because someone needs something and since there are rarely any
 long-term design decisions anymore, we’re stuck with new.target,
 function.sent, import.meta (add your own)

 Seriously. How is new.target is “syntax that has context
 information”, but 

Re: Object dynamic property with or

[Matthew Robb]

Why not this: `const { a = o.b } = o;`?

On Jun 15, 2017 4:59 AM, "T.J. Crowder" 
wrote:

FWIW, see

* [`||=` is much needed?](https://esdiscuss.org/topic/is-much-needed)
* [Proposal for a `null` coalescing operator](https://esdiscuss.
org/topic/proposal-for-a-null-coalescing-operator)

I'm sure there were others as well. There was an old strawman for a
"default operator" but the old wiki isn't accessible (right now? anymore?).

I'd love to see `??` (and `??=` for that matter), where the "falsiness" is
defined as the value is `null` or `undefined`, e.g.:

```js
a = b ?? c;
```

is in effect

```js
{
const temp = b;
a = temp === null || temp === undefined ? c : temp;
}
```

IIRC, in previous discussions there were firmly-held convictions for just
`undefined` and for both. In pure JavaScript terms, only considering
`undefined` as the falsy value would make sense, but A) `??` is established
as a `null`-coalescing operator elsewhere (e.g., C#), and B) JavaScript has
to interoperate with typed APIs like the DOM that use `null` to mean
"nothing." Contrived example:

```js
function foo(elm) {
elm ??= document.getElementById("y");
}
foo(document.getElementById("x"));
```

Default arguments don't work for the above because they only default on
`undefined`, not both. And in the previous discussions, people wanted `??`
in non-default-argument situations.

Given this has been kicking around for a long time, is there a will to
consider it if a proper proposal is made?

-- T.J. Crowder


On Thu, Jun 15, 2017 at 8:17 AM, somonek  wrote:

> Hi everyone,
>
> consider the following example:
>
> const myObj = {
> propertyOne: 'someValue',
> propertyTwo: 'another value',
> };
>
> suppose I have to get a non existing property dynamically with a
> fallback on another one:
>
> let myProp = myObj['propertyTwo'];
> if (myObj['propertyThree']) {
> myProp = myObj['propertyThree'];
> }
>
> wouldn't it be nice to have a quicker way of doing that like this?
>
> const myProp = myObj['propertyThree' || 'propertyTwo'];
> this will return undefined of course but some other operator could be used
> like:
> let myProp = myObj['propertyThree' ?? 'propertyTwo'];
> let myProp = myObj['propertyThree' ?? 'propertyFour' ?? 'propertyTwo'];
>
> any thoughts?
>
> cheers,
> Serghei
> ___
> 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

Re: Object Extract Method Suggestion

[Matthew Robb]

Personally I've been itching for object pattern-like pick syntax. I keep
finding myself doing the following pattern:

```
const {a=1,c=2} = obj;
return {a,c};
```

On May 8, 2017 6:37 AM, "Murat Gözel"  wrote:

> Hey everyone,
>
> The idea came up while i'm filtering spesific view of web page's text
> objects from whole context object. Objects are much more useful than any
> other type in many cases. I find myself working with more javascript
> objects project to project. Despite this, an object extract method can be
> useful for many cases. You can think of it as the opposite of assign
> method. It reduces the source object to a smaller object with only keys you
> spesified.
>
> Looks like this:
> ```javascript
> Object.extract(SourceObject, ArrayOfKeys)
> ```
>
> Example usage:
> ```javascript
> const contactPageExpressions = ['Follow Us', 'Phone', 'Email']
>
> const wholeContext = {
>   'Welcome': {
> translation: 'Welcome'
>   },
>   'Follow Us': {
> translation: 'Follow Us'
>   },
>   'Phone': {
> translation: 'Phone Number'
>   },
>   'Email': {
> translation: 'Email Address'
>   },
>   'News': {
> translation: 'News'
>   }
> }
>
> const activeContext = Object.extract(wholeContext, contactPageExpressions)
>
> // Now we have an object that only has keys we want:
> {
>   'Follow Us': {
> translation: 'Follow Us'
>   },
>   'Phone': {
> translation: 'Phone Number'
>   },
>   'Email': {
> translation: 'Email Address'
>   }
> }
> ```
>
> Since it works by matching keys, second parameter of the method can even
> be a regular expression:
>
> ```javascript
> // Get properties that has numbers.
> Object.extract(source, /[0-9]/g)
> ```
>
> Would like to hear your opinions.
>
> ___
> 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

Re: dynamic import() polyfill + question

[Matthew Robb]

I think that if an export is statically async that the promise should hold
up resolving that module as ready. When resolving the current dependency
graph.

On Apr 22, 2017 10:50 AM, "Andrea Giammarchi" <andrea.giammar...@gmail.com>
wrote:

> Cyril the discussion is now rather about about asynchronous export.
>
> However, what you linked is not a polyfill for import, that's more like a
> half backed require.
>
> The polyfill for dynamic import where you actually use `import(path)` as
> specified on stage 3 is here:
> https://github.com/WebReflection/import.js
>
> The universal attempt to add `.import()` as CommonJS module is here:
> https://github.com/WebReflection/common-js
>
> Latter does what you wrote but on both client and server (it also probably
> resolves relative paths in a slightly different (more accurate?) way.
>
> That pattern never convinced CommonJS chaps that believes nobody wants
> asynchronous requires in this world (I actually do as much as I want
> asynchronous exports too ^_^)
>
> Regards
>
>
>
> On Sat, Apr 22, 2017 at 3:41 PM, Cyril Auburtin <cyril.aubur...@gmail.com>
> wrote:
>
>> If the discussion is about a polyfill for import()
>> <https://github.com/tc39/proposal-dynamic-import> (not the static import)
>>
>> it's not too hard: https://gist.github.com/caub/4
>> 58cfe944f8abcf7b1aec608d0a878cc
>>
>> ```js
>> (async()=>{
>>   const [Stuff, {foo, bar}] = await Promise.all(['./x',
>> './y'].map(require));
>>   // ..
>> })()
>>
>>
>> ```
>>
>> 2017-04-22 16:31 GMT+02:00 Andrea Giammarchi <andrea.giammar...@gmail.com
>> >:
>>
>>> > Why not just allow `export await` in all export syntactic forms?
>>>
>>> that would work for me, and it would be like my initial, and second,
>>> example: `export default await Promise.all(...).then(...)`
>>>
>>> however, just to better understand what you're up to, I wonder if the
>>> module would be held, in a non blocking way, until all asynchronous exports
>>> have been resolved (desired) as opposite of introducing complexity for
>>> hybrid modules where you have to await everything to be sure it won't break
>>> (shenanigans)
>>>
>>> TL;DR unless the following would be possible too, please consider making
>>> modules available only once fully resolved through their exports
>>>
>>> ```js
>>> import await * as module from './module.js';
>>> ```
>>>
>>> Regards
>>>
>>>
>>>
>>>
>>> On Sat, Apr 22, 2017 at 3:08 PM, Matthew Robb <matthewwr...@gmail.com>
>>> wrote:
>>>
>>>> I know you probably didn't want things to go this direction in the
>>>> conversation but this made me think up a generic way to do this. Why not
>>>> just allow `export await` in all export syntactic forms? This would not be
>>>> the same as top level await but a signal that the export will be the result
>>>> of an asynchronous operation that follows the await.
>>>>
>>>> Then you could potentially do `export default await (async ()=>{
>>>>
>>>> })();`
>>>>
>>>> On Apr 21, 2017 3:10 PM, "Bradley Meck" <bradley.m...@gmail.com> wrote:
>>>>
>>>> > how's that different from a Promise ?
>>>>
>>>> `later` is not const and could change over time. Could even be set via
>>>> something like:
>>>>
>>>> ```
>>>> setInterval(() => later = Date.now(), 1e3);
>>>> ```
>>>>
>>>> On Fri, Apr 21, 2017 at 2:00 PM, Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com> wrote:
>>>>
>>>>> > let later;
>>>>> > export default {then(notify) { if (ready) notify(later); else
>>>>> queue(notify); }}
>>>>>
>>>>> how's that different from a Promise ?
>>>>>
>>>>> Don't get me wrong, I have a module [1] that does that already (use a
>>>>> symbol as key and that's it) but yet for an importer, if that has to be
>>>>> handled like a Promise, then why not just a Promise ?
>>>>>
>>>>> This is the bit I don't get.
>>>>>
>>>>> Thanks
>>>>>
>>>>> [1] https://github.com/WebReflection/broadcast#broadcast--
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 21, 2017 at 7:38 

Re: dynamic import() polyfill + question

[Matthew Robb]

I know you probably didn't want things to go this direction in the
conversation but this made me think up a generic way to do this. Why not
just allow `export await` in all export syntactic forms? This would not be
the same as top level await but a signal that the export will be the result
of an asynchronous operation that follows the await.

Then you could potentially do `export default await (async ()=>{

})();`

On Apr 21, 2017 3:10 PM, "Bradley Meck"  wrote:

> how's that different from a Promise ?

`later` is not const and could change over time. Could even be set via
something like:

```
setInterval(() => later = Date.now(), 1e3);
```

On Fri, Apr 21, 2017 at 2:00 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > let later;
> > export default {then(notify) { if (ready) notify(later); else
> queue(notify); }}
>
> how's that different from a Promise ?
>
> Don't get me wrong, I have a module [1] that does that already (use a
> symbol as key and that's it) but yet for an importer, if that has to be
> handled like a Promise, then why not just a Promise ?
>
> This is the bit I don't get.
>
> Thanks
>
> [1] https://github.com/WebReflection/broadcast#broadcast--
>
>
>
> On Fri, Apr 21, 2017 at 7:38 PM, Bradley Meck 
> wrote:
>
>> > how asynchronous export helps here ?
>>
>> >>> I cannot think about a single use case for wanting that: it's not
>> usable from within the module, it won't be usable outside unless checked
>> via ... an interval ?
>>
>> As stated in previous email:
>>
>> >> The previous email was stating there are use cases for updating
>> exports.
>>
>> If you are updating exports that in general means live bindings /
>> asynchronous work.
>>
>> > already covered by `export default new Promise(async () => {})` ,
>> right ?
>>
>> Kind of, this sacrifices live binding since `default` can only ever have
>> 1 value. Something could use a thenable to export multiple values over time
>> however similar to a live binding:
>>
>> ```
>> let later;
>> export default {then(notify) { if (ready) notify(later); else
>> queue(notify); }}
>> ```
>>
>> > how is the module consumer supposed to know when these exports are
>> ready?
>>
>> > if it's an event emitted, libraries trusting the event that already
>> happened will never know, so we are back to polling, which is a very bad
>> approach, IMO, and if the solution is a Promise then it's covered already.
>>
>> Please read my previous email:
>>
>> >> The answer is no pattern has been standardized so it depends on your
>> proposed solution. A `then()`-able is already in spec and seems like a
>> possible choice (though I wouldn't use a Promise); top level await could be
>> another but blocks the module graph. TDZ poll/checking on imports could be
>> another (though not-preferable) solution. I am sure we could bikeshed other
>> approaches.
>>
>> > so if two importers happen at different times the second importer can
>> compromise with undesired features the first one or vice-verssa?
>>
>> No, ESM modules are only evaluated once. Such checks are most likely done
>> up front. However, enabling a debugger for example might cause a new set of
>> exports to be loaded/exported.
>>
>> > So, like I've said, I don't see real-world scenarios for exported
>> modules that changes without notice.
>> It looks unpractical and undesired.
>>
>> As stated in previous email:
>>
>> > Exporting asynchronously doesn't provide any coordination point ...
>>
>> The rest of my email(s) have been talking about coordination.
>>
>> On Fri, Apr 21, 2017 at 1:28 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> > It could be something that is being mocked/spied upon.
>>>
>>> how asynchronous export helps here ?
>>>
>>>
>>>
>>> > It could be part of a circular dependency and so the modules do get a
>>> hold of eachother without finishing evaluation.
>>>
>>> already covered by `export default new Promise(async () => {})` , right ?
>>>
>>>
>>>
>>> > It could be that it lazily/async populates its exports due to costs.
>>>
>>> how is the module consumer supposed to know when these exports are ready?
>>>
>>> if it's an event emitted, libraries trusting the event that already
>>> happened will never know, so we are back to polling, which is a very bad
>>> approach, IMO, and if the solution is a Promise then it's covered already.
>>>
>>>
>>>
>>> > It could be that it is relying upon context to determine if something
>>> should be exported (debug flag etc.)
>>>
>>> so if two importers happen at different times the second importer can
>>> compromise with undesired features the first one or vice-verssa?
>>>
>>> Dynamic exports are possible since ever on CommonJS world (same as
>>> imports) and I've truly rarely seen the need to lazy export or lazy import.
>>> Conditional import yes, and conditional exports too but never at distance.
>>>
>>> So, like I've said, I don't see real-world scenarios for exported
>>> modules that 

Re: FW: Re: Strict Relational Operators

[Matthew Robb]

Also there was once the is/isnt operators and they lasted in ES6 for a very
long time and went pulled for reasons like this.

On Apr 15, 2017 4:06 AM, "Isiah Meadows"  wrote:

> Okay, I stand corrected... (I forgot about those)
>
> On Sat, Apr 15, 2017, 04:01 Jordan Harband  wrote:
>
>> There's also `instanceof`.
>>
>> On Fri, Apr 14, 2017 at 11:31 PM, T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>>> Happy with `neq`.
>>>
>>> > Up to date, the only keyword
>>> > operators have been exclusively unary, such as `typeof`, `await`,
>>> > and `yield`.
>>>
>>> Not quite. :-) As I mentioned when suggesting them originally, there is
>>> *one* binary non-symbolic operator already: `in`
>>>
>>> ```js
>>> if ("foo" in obj)
>>> ```
>>>
>>> So the concept of non-symbolic binary operators isn't entirely new to
>>> the parsing/grammar infrastructure.
>>>
>>> -- T.J. Crowder
>>>
>>> On Sat, Apr 15, 2017 at 4:42 AM, Isiah Meadows 
>>> wrote:
>>>
 So far, the only decent proposal I've seen here is the keyword
 operator idea. It looks operator-y, and it actually reads like what
 you expect. Few nits about the general idea, and most of these would
 probably keep TC39 from considering them:

 1. `neq` is better than `noteq`. 2 fewer characters for a common
 operation.

 2. JS is a weakly typed language, and coerces nearly everything. It
 normally calls `.valueOf()` (if it exists) and coerces the result to
 numbers for the comparison operators. Strong type checking has
 generally only been reserved for scenarios that can't be optimized
 well otherwise (like the length of typed arrays) or that require
 specific guarantees that coercion prevents (like uniqueness for weak
 collections).

 3. TypeScript and Flow both literally don't have this issue at all,
 and several members of TC39 actively use these in mission-critical
 code.

 4. JS has historically *avoided* keyword operators, electing to remain
 close-ish to its curly brace and punctuation-driven roots. Consider
 `=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
 operators have been exclusively unary, such as `typeof`, `await`, and
 `yield`. So this would face a potentially steep slope to acceptance.

 Just a bit of pessimistic pragmatism here.
 -

 Isiah Meadows
 m...@isiahmeadows.com


 On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin 
 wrote:
 > I prefer the idea of keyword operators, like :
 >
 >
 >
 > a lt 1 // strict < 1
 >
 > a lte 1 // strict <=1
 >
 > a gt 1 // strict > 1
 >
 > a gte 1 // strict >= 1
 >
 > ...
 >
 >
 >
 > That’s easier to understand and memorize.
 >
 >
 >
 > From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com]
 > Sent: Friday, April 14, 2017 5:12 AM
 > To: Jordan Harband 
 > Cc: es-discuss 
 > Subject: Re: Re: Strict Relational Operators
 >
 >
 >
 > [...]
 >
 >
 >
 > The =@=@= operator is probably easier to add and won't break the web.
 Also,
 > some basic pattern matching for functions would be useful and time
 saving
 > feature:
 >
 >
 >
 > [...]
 >
 >
 > ___
 > 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
>>>
>>>
>>
> ___
> 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

Re: Observable/Promise parallel control flow proposal

[Matthew Robb]

One major difference I can see is that the earliest async/await proposals
included `async *` which was eventually dropped for no practical reason
other than it seemed to add bloat to a spec that AT THE TIME looked like it
would be hard to push through the process. History tells a different story
for async/await and it may be better that it was actually left out
initially it's hard to say. What I can say is the use case has been a part
of the discussion from the very beginning for awaiting a list of things.

There really are two phases to your spec. A subset that can apply
immediately to the existing promise-based abstraction and a larger
extension of that which could apply to a wider range of async models such
as Observable. I think both are well represented but it would be helpful to
see them explicitly broken down into those two distinct sets.


- Matthew Robb

On Tue, Mar 7, 2017 at 7:03 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> I'll note that async functions had a similar thing going on, too. Most
> third-party libraries had most issues taken care of, but what landed
> in the spec was only a fraction of what most libraries provided. The
> Observable proposal is turning out to be similar in this respect.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Tue, Mar 7, 2017 at 6:23 AM, Matthew Robb <matthewwr...@gmail.com>
> wrote:
> > Isiah I think there is a lot of value in the work you have done here. I
> > think it would be useful to see this broken down in a way that makes
> solving
> > the Promise cases in a way that would be forward compatible with
> Observers
> > front and center. Right now it feels optimistically speculative because
> the
> > approach is treating Promise and Observable as equal edges to the problem
> > which may be true but today we have under facilitated Promise
> abstractions
> > and no one is feeling any pain/loss around missing Observable support
> (yet).
> >
> > Does any of that make sense?
> >
> >
> > - Matthew Robb
> >
> > On Sun, Mar 5, 2017 at 8:24 AM, Isiah Meadows <isiahmead...@gmail.com>
> > wrote:
> >>
> >> See: https://gist.github.com/isiahmeadows/
> ba298c7de6bbf1c36448f718be6a762b
> >>
> >> TL;DR: I've created a proposal to enable modelling of parallelism and
> >> non-linear control flow, to interoperate with the non-determinism of
> >> Promises and Observables. I drew inspiration from non-von Neumann
> >> paradigms in creating the primitive operations. I'm seeking feedback
> >> for potential improvements and just overall feelings on the idea.
> >>
> >> Obviously, this is blocked on the Observable proposal [1] getting
> >> completed, and may need edited accordingly. And I've already proposed
> >> a similar thing [2] in their repo, but not quite to this scale.
> >>
> >> [1]: https://github.com/tc39/proposal-observable
> >> [2]: https://github.com/tc39/proposal-observable/issues/141
> >>
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >> ___
> >> 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

Re: Observable/Promise parallel control flow proposal

[Matthew Robb]

Isiah I think there is a lot of value in the work you have done here. I
think it would be useful to see this broken down in a way that makes
solving the Promise cases in a way that would be forward compatible with
Observers front and center. Right now it feels optimistically speculative
because the approach is treating Promise and Observable as equal edges to
the problem which may be true but today we have under facilitated Promise
abstractions and no one is feeling any pain/loss around missing Observable
support (yet).

Does any of that make sense?


- Matthew Robb

On Sun, Mar 5, 2017 at 8:24 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> See: https://gist.github.com/isiahmeadows/ba298c7de6bbf1c36448f718be6a762b
>
> TL;DR: I've created a proposal to enable modelling of parallelism and
> non-linear control flow, to interoperate with the non-determinism of
> Promises and Observables. I drew inspiration from non-von Neumann
> paradigms in creating the primitive operations. I'm seeking feedback
> for potential improvements and just overall feelings on the idea.
>
> Obviously, this is blocked on the Observable proposal [1] getting
> completed, and may need edited accordingly. And I've already proposed
> a similar thing [2] in their repo, but not quite to this scale.
>
> [1]: https://github.com/tc39/proposal-observable
> [2]: https://github.com/tc39/proposal-observable/issues/141
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> ___
> 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

Re: How about awaiting Arrays ?

[Matthew Robb]

Honestly Isiah my largest motivation for thinking this is worth solving
boils down to the fact that async/await does a good job of hiding the
promise and generator based implementation under it but this falls down so
fast when adding Promise.all.

I'm helping a new person learn JavaScript right now and he's using fetch to
get some JSON. Explaining the first then returning res.json() and the
second one chaining as well as 'this' considerations was a disaster. He
conceptually understands asynchronous code so when I backed up and did the
same thing with async/await he just got it. Saving him from needing to
learn anything about promises until later on.

In my opinion if a layer of sugar doesn't fully abstract the layers it sits
upon then it's an incomplete and confusing feature. I'd go so far as to say
that async/await should always support every capability of promise without
anyone touching Promise directly.

On Mar 3, 2017 9:12 PM, "Isiah Meadows"  wrote:

> First, I'll start out with this: I tend to be very adverse to new syntax,
> but I'll draw exceptions for things that enable whole new ways of looking
> at and manipulating code, like async functions and decorators, or things
> that enable new functionality altogether, like `function.sent` or private
> class fields. Things that haven't hit that bar for me include the bind
> syntax proposal (beyond function pipelining) and the
> `await.all`/`await.race` idea here.
>
> BTW, I had some ideas on unifying that with observables at the syntax
> level here, particularly with my `parallel` and `await parallel` ideas
> there: https://github.com/tc39/proposal-observable/issues/141
>
> Basically, it unifies the common case of merging promises and observables
> with a fairly low syntactic footprint.
>
> As for `Promise.race`, I see it much less frequently, and it's much
> simpler and faster under the hood to implement due to less state needed, so
> I didn't see the need to add support for that.
>
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> On Fri, Mar 3, 2017 at 11:59 AM, Michał Wadas 
> wrote:
>
>> My mistake Array.from is not necessary because Promise.all accepts any
>> iterable.
>>
>> Though I don't believe .race to be common use case (especially when we
>> consider it's edge case with empty array).
>>
>> Hsving parity with spread and rest parameters seems consistent for me.
>>
>> On 3 Mar 2017 17:54, "T.J. Crowder" 
>> wrote:
>>
>>> On Fri, Mar 3, 2017 at 4:51 PM, Michał Wadas 
>>> wrote:
>>> > Actually I would go with
>>> >
>>> > await ...expr;
>>> >
>>> > As sugar for:
>>> >
>>> > await Promise.all(Array.from(expr))
>>>
>>> Which is great for `Promise.all`, but leaves us without `race` or things
>>> that may be added in future (like Andrea's `any`). (Granted `all` has to be
>>> the dominant use case...)
>>>
>>> Why the `Array.from` part of that?
>>>
>>> -- T.J.
>>>
>>
>> ___
>> 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

Re: How about awaiting Arrays ?

[Matthew Robb]

I think this conversation needs to happen but I am not sure baking it into
Array facilities makes the most sense.

In my experience with async/await I am very often needing Promise.all but
in some cases the other forms of multi promise capabilities. What if we
expanded the keyword `await.all [...]; await.race [...]` or add a new
context for `of` outside for loops but this would be limited to P.all
behavior `await of [...]`?


- Matthew Robb

On Fri, Mar 3, 2017 at 9:47 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> If this is what we gonna have
>
> `[].promiseAll`
>
> then I'd rather
>
> `Promise.all()`
>
>
> You made some fair point, I guess there's nothing to see here.
>
> Regards
>
>
> On Fri, Mar 3, 2017 at 2:12 PM, T.J. Crowder <tj.crowder@farsightsoftware.
> com> wrote:
>
>> On Fri, Mar 3, 2017 at 12:43 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>> > Not the first time I accidentally type the following:
>> >
>> > ```js
>> > const allTheThings = await [pa, pb, pc];
>> > ```
>> >
>> > I am assuming that JS will implicitly realize that'd be a
>> > `Promise.all([pa, pb, pc])` call but nope.
>>
>> The problem is that an array of promises is a perfectly valid promise
>> resolution value. (And that the proposal is now at Stage 4. :-) ) To
>> do this, `await` would have to treat arrays specially in a way that
>> promises don't. That seems like something `await` shouldn't do. You
>> might propose `awaitall`, `awaitany`, `awaitrace` or similar...
>>
>> > Then I also realize it'd be cool to have other shortcuts too that
>> > play nice with arrays such:
>> >
>> > ```js
>> > Array.prototype.all = function all() { return Promise.all(this); };
>> > Array.prototype.race = function race() { return Promise.race(this); };
>>
>> Side note: I'm fairly sure `all` isn't websafe as an `Array.prototype`
>> function (isn't that why ES5 used `every`?).
>>
>> I don't think arrays need special promise-related functionality in the
>> standard lib.  But if they got it, I'd want it to be reflected in the
>> naming, e.g. `[].promiseAll`, `[].promiseAny`, ... Both for clarity and
>> for web safety (I'm fairly sure `all` on `Array.prototype` wouldn't be
>> web-safe).
>>
>> -- T.J.
>>
>
>
> ___
> 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

Re: Proposal: Improve syntax for inline anonymous class instantiations

[Matthew Robb]

For some reason this idea made me think about adding extends to function
syntax:
```
class Foo {}

function Bar(a, b) extends Foo {
  // ...
}

// Basic sugar for

function Baz(a, b) {
  // ...
}

Object.setPrototypeOf(Baz, Foo);
Object.setPrototypeOf(Baz.prototype, Foo.prototype);

```

Although now that I re-read the original post I don't think this addresses
the same scenario


- Matthew Robb

On Fri, Jan 6, 2017 at 5:11 PM, Igor Vaynberg <igor.vaynb...@gmail.com>
wrote:

> Given a simple class with an abstract method "populateItem"
>
> class ArrayView extends Container {
> constructor(id, model) {
> super(id);
> this.model = model;
> }
>
> // methods referencing "populateItem" omitted for clarity
> }
>
> the current anonymous instantiation syntax looks like this:
>
> this.add(new class extends ArrayView {
> populateItem(item) {
> item.add(new Checkbox("check", new PropertyModel(item.model,
> "done")));
> item.add(new Label("title", new PropertyModel(item.model,
> "title")));
> }
> }
> ("items", itemsModel)
> );
>
> The problem with this syntax is that it pushes the constructor
> parameters below the class body which I think causes two problems:
>
> When scanning code constructors often contain the piece of information
> that helps locate the anonymous class, which currently requires the
> developer to look back. This is especially problematic for anonymous
> classes with long class bodies.
>
> When writing code I usually think about the constructor first, so it
> seems it would be preferable to write it before moving onto working on
> the class body. This is also the reason why constructors are usually
> placed toward the top of named classes' source.
>
> A better syntax would move the constructor parameters between the
> super class name and the class body:
>
> this.add(new class extends ArrayView("items", itemsModel) {
> populateItem(item) {
> item.add(new Checkbox("check", new PropertyModel(item.model,
> "done")));
> item.add(new Label("title", new PropertyModel(item.model,
> "title")));
> }
> });
>
> If possible it would also be great to get rid of the "class extends"
> keywords for this usecase:
>
> this.add(new ArrayView("items", itemsModel) {
> populateItem(item) {
> item.add(new Checkbox("check", new PropertyModel(item.model,
> "done")));
> item.add(new Label("title", new PropertyModel(item.model,
> "title")));
> }
> });
>
> Thoughts?
>
>
> Thanks,
> -igor
> ___
> 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

Re: Extended dot notation (pick notation) proposal

[Matthew Robb]

​First I'd like to state that I don't mean to suggest that this is
"simple", in practical terms, as either a spec change or in application of
the feature in day-to-day code.​

On Thu, Sep 22, 2016 at 11:24 AM, Jason Orendorff <jason.orendo...@gmail.com
> wrote:

> I get that to you, that's all it is. But I have trouble seeing how that is
> true in any objective sense. In the spec


​​The point I was trying to make is that "to me" is exactly the perspective
I was hoping to share as people writing JavaScript don't have an intimate
understanding of the spec more often than not. In teaching people who spend
most of their time writing JavaScript where each line starts with `$(...)`
I get more questions about things that look like they should work some way
in one place because it actually works that way in another than anything
else.

I don't seek to trivialize either side of the argument but with syntax in
particular I would hope that complexity additions be back-loaded into the
spec rather than front-loaded onto users.

I apologize FOR MY USE OF CAPS TO EXPRESS emphasis. It's a bad habit :P



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extended dot notation (pick notation) proposal

[Matthew Robb]

On Wed, Sep 21, 2016 at 10:40 AM, Jason Orendorff <jason.orendo...@gmail.com
> wrote:

> Since all new syntax imposes some mental load on all language users, the
> answer should be no unless the benefit is really dramatic, which I don't
> think it is here.


For the most part I can completely agree with the sentiment that all new
syntax imposes some mental load on all language users but my question is
how this applies when syntax RESTRICTIONS that seem counter-intuitive
impose their OWN mental load.

I think the inspiration of this thread and the few before it comes from the
fact that destructuring syntax and object literal shorthand syntax seem to
share in a root syntax yet the two features are incompatible which makes
the mental load of the restrictions more obvious.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import wildcards

[Matthew Robb]

On Sun, May 29, 2016 at 4:01 PM, Maël Nison <nison.m...@gmail.com> wrote:

> effectively exporting indirectly those symbols (since you need to parse
> the imported module to know which symbols will be available).


​The difference with `export * from '...';` syntax is that it doesn't
indirectly introduce named bindings into a scope. If you want a named
binding you must explicitly declare it. The reasons are numerous but a goal
is to keep as much of the module syntax statically analyzable.​ Using the
`import * as dotdotdot from '...';` syntax skirts this a bit and is in
place for usages precisely like your own.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import wildcards

[Matthew Robb]

Not exactly. To export a binding it must be declared in scope somewhere
which means it's statically analyzable within a given file.
On May 28, 2016 9:49 AM, "Maël Nison"  wrote:

> I see, but unless I'm mistaken, the same issue occurs with the export *
> from '...' syntax, right ?
>
> Le ven. 27 mai 2016 à 16:06, Kevin Smith  a écrit :
>
>> With this syntax, you would not be able to statically tell whether a
>> particular variable name (e.g. API_FOO) is bound to a module import,
>> without also analyzing the dependencies (and perhaps their dependencies).
>> These considerations killed the original "import all" syntax.  (`import *
>> from 'foobar'`);
>>
>> If repitition is an issue, use the namespace import form.
>>
>> import * as constants from 'config';
>>
>>
>> On Fri, May 27, 2016 at 10:00 AM Maël Nison  wrote:
>>
>>> Hi,
>>>
>>> In about every project I have, I write a file or two with this form:
>>>
>>> export let API_USERNAME = `name`
>>> export let API_TOKEN = `token`
>>> // etc
>>>
>>> Most of the time, when I need one of those variables somewhere, I also
>>> need the other. It might be burdensome, since I end up with something
>>> similar to this:
>>>
>>> import { API_USERNAME } from 'config';
>>> import { API_TOKEN } from 'config';
>>> // etc
>>>
>>> Of course, I can import all of these token in a single line, but it
>>> doesn't help readability when there is a lot of entries (we all know that
>>> configuration files always end up with a fair number of variables - and
>>> let's not talk about parsers and similar). Plus, it's not very fun to
>>> explicitely write all these names when I just want to tell the engine that
>>> I will need everything similar, pretty please.
>>>
>>> Now as for the request: what would you think about adding a new syntax
>>> -nothing too fancy- to import all the symbols that match a *static *pattern?
>>> In the spirit of the `export * from ...` syntax, I feel like the following
>>> could be interesting:
>>>
>>> import { API_* } from 'config';
>>>
>>> As for the bad part: there really isn't, actually. This syntax is
>>> familiar with every developer that used globing before, and gives just
>>> enough insight to someone looking at the source code to understand that a
>>> variable named `API_SOMETHING` has been imported from a parent module.
>>> Linters would also be able to help in this regard, since they would just
>>> have to blacklist declaring variables that would conflict with an import
>>> prefix.
>>>
>>> Any thoughts ?
>>>
>>> ___
>>> 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

Re: Promises, async functions, and requestAnimationFrame, together.

[Matthew Robb]

This is definitely interesting stuff. Have you considered rewriting this so
that it only uses generators? If you did then you could test natively in
Chrome and see if you get the same results.


- Matthew Robb

On Sat, Apr 23, 2016 at 7:01 PM, /#!/JoePea <j...@trusktr.io> wrote:

> Just to show a little more detail, here's a screenshot that shows that
> the logic of the while-loop version of my animation loop fires inside
> each animation frame. I've zoomed out and we can see there's nothing
> fired between the frames:
>
>
> https://cloud.githubusercontent.com/assets/297678/14764323/c28e83cc-0968-11e6-8771-8e726158aa52.png
>
> On Sat, Apr 23, 2016 at 3:18 PM, /#!/JoePea <j...@trusktr.io> wrote:
> > Alright, I did an experiment, and I'm really surprised at the results!
> > Apparently, the logic (what would be drawSomething() in my previous
> > example) is fired within the frame!!
> >
> > So, let me show you my original method for starting an animation loop.
> > I'm working on a 3D project at http://infamous.io. The Scene class
> > (https://github.com/infamous/infamous/blob/master/src/motor/Scene.js)
> > has a method for starting an animation loop the standard way:
> >
> > ```js
> > async _startAnimationLoopWhenMounted() {
> > this._animationLoopStarted = true
> >
> > if (!this._mounted) await this.mountPromise
> >
> > // So now we can render after the scene is mounted.
> > const loop = timestamp => {
> > this._inFrame = true
> >
> > this._runRenderTasks(timestamp)
> > this._renderNodes(timestamp)
> >
> > // If any tasks are left to run, continue the animation loop.
> > if (this._allRenderTasks.length)
> > this._rAF = requestAnimationFrame(loop)
> > else {
> > this._rAF = null
> > this._animationLoopStarted = false
> > }
> >
> > this._inFrame = false
> > }
> >
> > this._rAF = requestAnimationFrame(loop)
> > }
> > ```
> >
> > Here's what the Chrome timeline shows for the logic that is fired
> > inside the loop:
> >
> https://cloud.githubusercontent.com/assets/297678/14764236/8eb72d4a-0965-11e6-9bb9-5db02cc23520.png
> >
> > Now, I went ahead and modified my Scene class so the method now looks
> like this:
> >
> > ```js
> > function animationFrame() {
> > let resolve = null
> > const promise = new Promise(r => resolve = r)
> > window.requestAnimationFrame(resolve)
> > return promise
> > }
> >
> > // ...
> >
> > async _startAnimationLoopWhenMounted() {
> > this._animationLoopStarted = true
> >
> > if (!this._mounted) await this.mountPromise
> >
> > this._rAF = true
> > let timestamp = null
> > while (this._rAF) {
> > timestamp = await animationFrame()
> > this._inFrame = true
> >
> > this._runRenderTasks(timestamp)
> > this._renderNodes(timestamp)
> >
> > // If any tasks are left to run, continue the animation loop.
> > if (!this._allRenderTasks.length) {
> > this._rAF = null
> > this._animationLoopStarted = false
> > }
> >
> > this._inFrame = false
> > }
> > }
> > ```
> >
> > And the timeline results are surprising! As you can see in the
> > following screenshot, all of the logic happens within the frame
> > (though you can see there's extra overhead from what I assume are the
> > extra function calls due to the fact that I'm using Facebook
> > Regenerator for the async functions):
> >
> https://cloud.githubusercontent.com/assets/297678/14764237/8eb71ce2-0965-11e6-942a-3c556c48b9a0.png
> >
> > Near the bottom right of the screen shot, you can see the tooltip as
> > I'm hovering on the call to `animationFrame` which returns the promise
> > that I am awaiting in the loop.
> >
> > Although this behavior seems to be exactly what I was hoping for, it
> > seems like there is something wrong. Could there be a bug in
> > regenerator that is failing to defer my loop code to a following tick?
> > Or is my code deferred to a following tick that somehow the animation
> > frame knows to execute within the same tick? Maybe there's something
> > I'm missing about the Promise API that allows for .then() of a promise
&

Re: Import wildcards on the right side of the statement

[Matthew Robb]

This could be made to work as a feature in the server side. Basically you
are asking the server to give you a virtual rollup module where the body is
basically just a bunch of export * from 'x';. Where even that gets sticky
though is when dealing with default exports.
On Apr 21, 2016 7:11 AM, "kdex"  wrote:

> A browser couldn't possibly resolve globs at runtime without you providing
> some additional information to the runtime environment, so I don't see how
> this could be implemented.
> It's not really about browsers, anyway; the ES environment knows nothing
> about files, either. (meaning that `require` is something on top of v8 and
> doesn't belong to the language at all.)
>
> Even if you were to resolve these globs *somehow*; this could have huge
> impacts on performance, since the result of a glob is dynamic. Also, wasn't
> the `import` syntax supposed to
> be statically analyzable anyway?
>
> One could, however, try to make this work with a babel transform that
> transforms globs into multiple `import` statements.
> Then again, I neither think that a syntax shouldn't depend on its
> underlying file system nor that this would solve a case where you'd have:
>
> ```js
> import * as SingleBinding from "./some/glob/**/*.js";
> ```
>
> A cleaner pattern would be to import one single module that, itself,
> imports only the modules that it needs.
>
> On Donnerstag, 21. April 2016 09:36:51 CEST Francisco Méndez Vilas wrote:
> > Hi all,
> >
> > This is my very first proposal here, so please let me know if i'm not
> > following some rules.
> >
> > I want to make a proposal around the "import" syntax, it is, for
> instance:
> >
> > import * from 'shared/features/**/reducers';
> >
> > or
> >
> > import * from many 'shared/features/**/reducers';
> >
> > This came to my mind when developing an isomorphic Redux application
> where
> > i had to import all reducers of each feature. My tree structure looks
> more
> > or less like that:
> >
> > + shared
> >   + features
> >  + todos
> >+ actions
> >+ components
> >+ reducers
> >  - TodoReducer.js
> >  - index.js
> >  + users
> >+ actions
> >+ components
> >+ reducers
> >  - UserReducer.js
> >  - index.js
> >
> > If i have to import every "index.js" below each "reducers" directory, i
> > have two options, either manually import each of them or prepare a script
> > to walk through the tree and import them. Both of the approaches are
> really
> > weird.
> >
> > I really would like to have that feature in the language. What do you
> think?
> >
> > Cheers,
> > Francisco Méndez Vilas
> >
> ___
> 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

Re: Function#toString revision: JSDoc comments?

[Matthew Robb]

Could it be doable to add a separate new property or something to a
function that attaches it's preceding comment content or is a "verbose"
toString alternative.


- Matthew Robb

On Mon, Apr 18, 2016 at 11:40 AM, Andy Earnshaw <andyearns...@gmail.com>
wrote:

> I imagine there's code in the wild that predates function.name, looking
> something like this:
>
> var fooName = foo.toString().match(/^function (\w+)/)[1];
>
> If a newer browser adds a preceding comment to the function then this code
> will break.  The top voted answer to a question[1] on Stack Overflow would
> break if the comment contained the string 'function '.
>
> [1]: http://stackoverflow.com/q/2648293
>
> On Sun, 17 Apr 2016 at 11:07 Isiah Meadows <isiahmead...@gmail.com> wrote:
>
>> I don't like the idea of including preceding comments in
>> `Function.prototype.toString` itself on grounds it's harder to parse for
>> other related reasons.
>>
>> As for anything including preceding comments, I'd be happy with something
>> somewhat independent, as long as it's not requiring JSDoc to be parsed. Not
>> that I have issues with that documentation format, but I don't think it
>> should be in the spec itself.
>>
>> On Sat, Apr 16, 2016, 13:29 Jordan Harband <ljh...@gmail.com> wrote:
>>
>>> As I see it, the primary purpose of the `Function#toString` proposal is
>>> to document what browsers already do, and tighten it down so they can't
>>> deviate further (which some browsers already have begun to do with "class",
>>> for example).
>>>
>>> "Preceding comments" would be a very hard thing to specify without
>>> unduly blessing an arbitrary documentation pattern, especially one that
>>> isn't universally considered to be a good thing.
>>>
>>> Reflection methods on functions are certainly a potential separate
>>> proposal, if you can make a compelling argument that it's a good idea to
>>> reflect on functions in this manner.
>>>
>>> On Sat, Apr 16, 2016 at 9:42 AM, Marius Gundersen <gunder...@gmail.com>
>>> wrote:
>>>
>>>> Would it not be better to expose the names (and default values,
>>>> destructurings, etc) of the function arguments using reflection? For
>>>> example, Reflection.arguments(Math.max).then this method can return any
>>>> JSDoc it is able to parse.
>>>> On 16 Apr 2016 16:53, "Caitlin Potter" <caitpotte...@gmail.com> wrote:
>>>>
>>>>> How would that interact with angular.js' Function.prototype.toString
>>>>> parsing? Seems like doing that could break some content, even if it were
>>>>> useful
>>>>>
>>>>> On Apr 16, 2016, at 10:48 AM, Axel Rauschmayer <rausc...@icloud.com>
>>>>> wrote:
>>>>>
>>>>> Regarding this proposal:
>>>>> https://github.com/tc39/Function-prototype-toString-revision
>>>>>
>>>>> Wouldn’t it make sense to include a preceding JSDoc-style comment in a
>>>>> function’s (or method’s) `[[SourceText]]` value? Conceptually it is a part
>>>>> of the function and it could be used to implement a REPL `help()` 
>>>>> function.
>>>>>
>>>>> --
>>>>> Dr. Axel Rauschmayer
>>>>> a...@rauschma.de
>>>>> rauschma.de
>>>>>
>>>>> ___
>>>>> 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
>>>>
>>>>
>>> ___
>>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

[Matthew Robb]

On Thu, Nov 5, 2015 at 12:49 PM, Tom Van Cutsem <tomvc...@gmail.com> wrote:

> O.o is a much safer alternative to Proxy.startTrapping and covers at least
> part of its use cases.


​Hmm.

Okay so pretend all object's are really just proxies to whatever their
internal backing might be. In this scenario perhaps what we might want is
`Proxy.observeTraps` which should work just like Object.observe only
synchronously and without a baked in ability to intercede. One could,
however, respond to a set operation by resetting the old value. What this
does is give you something VERY close to a built in observable Model type
on top of plain objects.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

[Matthew Robb]

On Wed, Nov 4, 2015 at 4:46 PM, Tom Van Cutsem <tomvc...@gmail.com> wrote:

> 1) If a module A hands out a reference to, say, a function f to modules B
> and C, then C could use this primitive to replace f with its own proxied
> version. Module B expects f to work as A intended, but module C can
> completely override its behavior, stealing any arguments to the function
> that B would pass. This is really bad behavior from a security and
> modularity perspective.


​It seems like a straight forward solution for this might be adding
something like `Proxy.preventTrapping(...)` and have this applied to all
module exports/imports by default. Since modules work off bindings and not
object properties.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

[Matthew Robb]

Isiah, could you elaborate some? I can't quite tell if you are expressing
support for my suggestion or not. Thanks!
On Nov 3, 2015 12:13 PM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:

> Lol... I feel I'm in an insane minority that can work relatively
> productively in Java 7 and Haskell both.
>
> Of course, I have a preference, but that preference lies around that of
> OCaml and Clojure. It's more the expression-based, impure functional
> languages that I'm most productive in. Observing mutations that I react to
> using immutable data structures. Sounds very odd and/or blasphemous to
> some, but that's what I like. MVC models like that are how Mithril and
> similar smaller frameworks have started to get some attention. It prefers
> highly local state, and an observed object would be a great state model for
> that.
>
> And on that note, I'm going to stop before I derail the topic too far.
>
> On Tue, Nov 3, 2015, 11:26 Andrea Giammarchi <andrea.giammar...@gmail.com>
> wrote:
>
>> That would make functional-programming-oriented developers wining forever
>> about such monstrosity in  specs ... I'd personally love such possibility!
>>
>> Regards
>>
>> On Tue, Nov 3, 2015 at 2:41 PM, Matthew Robb <matthewwr...@gmail.com>
>> wrote:
>>
>>> I probably have a terrible understanding of how this all works at a low
>>> level but I feel like a potential solution would be a method of "upgrading"
>>> a non-proxy object to be a proxy. The reason accessors are being used as
>>> they are now is because you can retro fit them. Maybe what I am suggesting
>>> is essentially like swapping out the internal pointer of an object with
>>> another object (such as the way live module bindings work). In this way you
>>> might upgrade an existing object to behave like a proxy.
>>>
>>>
>>> - Matthew Robb
>>>
>>> On Tue, Nov 3, 2015 at 3:20 AM, Tom Van Cutsem <tomvc...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> 2015-11-02 23:34 GMT+01:00 Coroutines <corouti...@gmail.com>:
>>>>>
>>>>> I come from Lua.  In Lua we make proxy objects with metamethods.  You
>>>>> create an empty table/object and define a metatable with a __index and
>>>>> __newindex to catch accesses and changes when a key/property doesn't
>>>>> exist.  I would primarily use this in sandboxes where I wanted to
>>>>> track the exact series of operations a user was performing to modify
>>>>> their environment (the one I'd stuck them in).
>>>>
>>>>
>>>> For this type of use case, you can use an ES6 Proxy <
>>>> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy>.
>>>> You can think of the proxy handler's methods as the 'metamethods' of the
>>>> proxy object.
>>>>
>>>> What O.o would provide beyond Proxy is the ability to observe changes
>>>> to already pre-existing objects. However, since you mention you'd start
>>>> with an empty table/object, you should be able to create a fresh Proxy and
>>>> use that to trace all property accesses.
>>>>
>>>> Proxies are particularly well-suited when you want to sandbox things,
>>>> since you should be in control of the sandboxed environment anyway and can
>>>> set-up proxies to intermediate. O.o is particularly well-suited to
>>>> scenarios where there are already plenty of pre-existing objects and you
>>>> don't know ahead of time which ones to observe and which not.
>>>>
>>>> Cheers,
>>>> Tom
>>>>
>>>> ___
>>>> 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
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

[Matthew Robb]

I probably have a terrible understanding of how this all works at a low
level but I feel like a potential solution would be a method of "upgrading"
a non-proxy object to be a proxy. The reason accessors are being used as
they are now is because you can retro fit them. Maybe what I am suggesting
is essentially like swapping out the internal pointer of an object with
another object (such as the way live module bindings work). In this way you
might upgrade an existing object to behave like a proxy.


- Matthew Robb

On Tue, Nov 3, 2015 at 3:20 AM, Tom Van Cutsem <tomvc...@gmail.com> wrote:

>
> 2015-11-02 23:34 GMT+01:00 Coroutines <corouti...@gmail.com>:
>>
>> I come from Lua.  In Lua we make proxy objects with metamethods.  You
>> create an empty table/object and define a metatable with a __index and
>> __newindex to catch accesses and changes when a key/property doesn't
>> exist.  I would primarily use this in sandboxes where I wanted to
>> track the exact series of operations a user was performing to modify
>> their environment (the one I'd stuck them in).
>
>
> For this type of use case, you can use an ES6 Proxy <
> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy>.
> You can think of the proxy handler's methods as the 'metamethods' of the
> proxy object.
>
> What O.o would provide beyond Proxy is the ability to observe changes to
> already pre-existing objects. However, since you mention you'd start with
> an empty table/object, you should be able to create a fresh Proxy and use
> that to trace all property accesses.
>
> Proxies are particularly well-suited when you want to sandbox things,
> since you should be in control of the sandboxed environment anyway and can
> set-up proxies to intermediate. O.o is particularly well-suited to
> scenarios where there are already plenty of pre-existing objects and you
> don't know ahead of time which ones to observe and which not.
>
> Cheers,
> Tom
>
> ___
> 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

Re: Decorators for functions

[Matthew Robb]

Why not just do:

```
const {myFunc} = {
  @someDecorator;
  myFunc() {

  }
};
```


- Matthew Robb

On Tue, Oct 20, 2015 at 9:00 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> You completely misunderstood me Bob, I don't think there's any valid use
> case for functions at all, including methods and ... .**specially**
> methods!!!
>
> I was thinking about decorators for classes, when you enrich their
> prototype in case the decorator receives a function instead of an object,
> or you enrich the object in every other case.
>
> You transform at runtime prototype methods??? Good for you, but that's
> something I'd never do, unless we are talking about lazy evaluation on the
> instance, where I don't see how lazy evaluation for an inherited method has
> anything to do with *functions* decorators.
>
> The difference is huge, methods will most likely have a `this` reference
> to be promoted on eventually, in  the other case you have a function that
> unless its body has "switches" can cannot really promote much by itself and
> passing it around as higher order function that mutates? ... yak!
>
> As summary: does anyone has a valid use case for a generic function
> decorator? 'cause I still don't see one, and having decorators for any sort
> of function would be problematic in terms of code portability, which is all
> I am saying.
>
> Regards
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 20, 2015 at 1:40 PM, Bob Myers <r...@gol.com> wrote:
>
>> So wait, you agree there are valid use cases for decorating functions
>> when they are methods on an object (although I don't see much along that
>> line in the proposal). But if the function is "stand-alone" suddenly the
>> use cases evaporate?
>>
>> For example, I hack on and off on a framework involving transforming
>> functions into self-updating versions of themselves. Of course I can write
>> this as
>>
>> self_updatify(function a() { })
>>
>> but it would be more compact and readable to say
>>
>> @self_updatify
>> function a() { }
>>
>> Which is, please correct me if I'm wrong, all decorators are about. To
>> take one example, Ember wants to use decorators not to get new
>> functionality, but to make the writing of computed properties less ugly,
>> among other reasons. (The fact that Ember makes little use of non-method
>> functions may also be one reason for the low priority placed on figuring
>> out how to decorate functions.)
>>
>> We can work to develop more examples and motivations and use cases for
>> decorated functions, although frankly it seems a little odd, as I mentioned
>> above, that there could be compelling use cases for decorated methods but
>> not for decorated functions. For the purposes of this discussion I will
>> stipulate that having decorated functions is an idea worth pursuing. If you
>> disagree, there's not point in reading further (but you might want to stop
>> and ask yourself why if it's such a great idea to have decorated methods,
>> no-one will ever want decorated functions).
>>
>> The only problem as far as I am aware is how to handle hoisting.
>>
>> AFAICS, hoisting is not an issue if the decorator has no side effects. Of
>> course there is nothing wrong with writing decorators with side effects,
>> and there are valid use cases for doing so, but they are rare. Furthermore,
>> even if a decorator does have side-effects, in only some subset of such
>> cases will the side effects together with hoisting result in unexpected
>> behavior.
>>
>> So to say that we will simply give up on decorated functions because of
>> the few cases where decorators have side effects, and those side effects
>> cause unexpected behavior due to hoisting, is really throwing out the baby
>> with the bathwater. We are telling people that you cannot decorate
>> functions at all, ever, or to decorate functions they must wrap them in a
>> class or object, because of some potentially unexpected behavior in what is
>> decidedly an edge case.
>>
>> Various proposals have been made on this topic, including hoisting
>> separately from decorating, hoisting and decorating at the same time,
>> change hoisting behavior for decorated functions, etc. etc. Each of these
>> ideas has its proponents and those who think it is the work of the devil. I
>> will not go into the details of these approaches here, and to do so is
>> actually a bit above my pay grade.
>>
>> I would just say that it is odd in the extreme that a group of
>> world-leading language designers would jus

Re: Global lexical tier

[Matthew Robb]

Personally I am a fan of Chrome's CURRENT solution:
```
Uncaught SyntaxError: Block-scoped declarations (let, const, function,
class) not yet supported outside strict mode
```


- Matthew Robb

On Mon, Aug 31, 2015 at 12:08 PM, Jason Orendorff <jason.orendo...@gmail.com
> wrote:

> Hi everyone. Can we talk about the global lexical tier?
>
> This was a mistake, a real blunder. We all should have known better.
> An extensible intermediate scope implies dynamic scoping. The referent
> of an identifier can change only once, but it can change. It's like an
> implicit `with` block around *all code*.
>
> This pattern for declaring variable in multiple scripts won't work
> with let/const:
>
> var MyES3Module = MyES3Module || {};
>
> There's no workaround except "keep using var".
>
> It's now possible to get a binding permanently wedged, which is bad for a
> REPL:
>
> js> let z = Maht.PI;  // oops, typo
> ReferenceError: Maht is not defined
> js> z
> ReferenceError: binding is not initialized: "z"
> js> z = 1;
> ReferenceError: binding is not initialized: "z"
> js> delete z;
> false
> js> let z = 1;
> SyntaxError: redeclaration of variable: "z"
>
> For a single name to have two global bindings, both mutable, is
> astonishing.
>
> All of this was unnecessary. What's the benefit to users? We ran
> roughshod over existing practice, invariants, and expectations in
> order to obtain a kind of self-consistency for `let` that users don't
> expect or even care about.
>
> We should have just made toplevel let/const/class create global
> properties, like var. This is how it was proposed originally and how
> Babel implements it today. For SpiderMonkey, switching to the worse,
> less user-friendly way without regressing performance is
> time-consuming.
>
> We knew all this. We didn't evaluate it correctly. What we
> particularly missed is that we already had modules as the way forward
> to a nice toplevel lexical tier, and weird half measures for scripts
> were pointless.
>
> -j
> ___
> 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

Re: System.import()?

[Matthew Robb]

I think a nice syntax would be allowing you to CALL import as a function
from within function bodies to get contextual dynamic loading that is still
SORT OF analyzable. It would also be nice if these import calls could
SOMEHOW work like async function calls and not require direct interaction
with a promise or callback. But I just work up so I may still be dreaming.


- Matthew Robb

On Wed, Aug 19, 2015 at 6:46 AM, Guy Bedford guybedf...@gmail.com wrote:

 It's great to see more interest in dynamic loading here.

 The contextual loader may be worth considering as a focus here - this is
 the special contextual loading syntax to effectively provide a scoped
 System.import call whose referrer is locked to the current module (`import
 module from this` as Dave has put in the roadmap, but I'm not sure what the
 exact syntax proposal is).

 This is the equivalent of the dynamic require in Node.

 As syntax it seems that would be in ECMA-262, and also might avoid the
 async Promise issues to share with Node as it can be entirely
 implementation-specific.

 Having a spec for this syntax would certainly be beneficial as it would
 immediately enable transpilers and module loading environments to then
 provide the dynamic loading feature, without other specification effort
 necessary.


 On Wed, Aug 19, 2015 at 10:38 AM Isiah Meadows isiahmead...@gmail.com
 wrote:

 There are ways for syncing promises for Node compatibility, although they
 all lie in C++ land. Similar has already been done with Node callbacks.

 https://www.npmjs.com/package/sync

 (You could also spawn a thread, block for a message, and join it with the
 promise result from a C++ callback from a thenable.)

 On Tue, Aug 18, 2015, 18:06 Bradley Meck bradley.m...@gmail.com wrote:

 The problem is timing; WHATWG uses promises, which Node cannot use due
 to existing code bases on npm + potential mixing w/ `require`. This causes
 time discrepancies and would mean different actions depending on how
 exactly hooks are specced out. Node does not want to prevent async loading
 on the browser, and the WHATWG loader does not want to cause breakage in
 Node.

 On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff 
 jason.orendo...@gmail.com wrote:

 On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com
 wrote:
  This would assume they can support the transformation hooks to do
 things
  like load coffeescript etc. right now, which is the main contention
 point.

 It is a perfectly ordinary occurrence in software to ship some
 capability at one point, and ways of customizing that capability
 later.

 -j


 ___
 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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: System.import()?

[Matthew Robb]

It seems to me that what is needed is something like what used to be
System.get().

In an async environment this should return nothing if it's not already
loaded but in sync environments it could be treated as the imperative API
for sync module loading and go through the same loader steps as
System.import but perhaps with no async wrappers?


- Matthew Robb

On Tue, Aug 18, 2015 at 1:11 PM, Domenic Denicola d...@domenic.me wrote:

 From: Jason Orendorff [mailto:jason.orendo...@gmail.com]

  HostResolveImportedModule is widely implemented by compilers, though
  not by browsers. People are writing, using, and sharing ES6 modules
 today.

 So what is your proposal then? Just standardize the node module resolution
 algorithm, since that is what transpilers are doing?

  It is working, and the people using it have a need for the dynamic API
 to go
  along with the static syntax, for reasons I pointed out in the initial
 post.

 It is not working outside of transpilers, which implement nonstandard
 resolution algorithms. The same transpilers implement JSX, but I don't
 think we'd take that as a reason to say that JSX is working and now let's
 start discussing how to standardize a reflective JSX layer.

 ___
 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

Re: Syntax shortcut for accessing properties on the current context (this)

[Matthew Robb]

does it seem reasonable though that if properties get initializers in the
class body that they could be considered in scope to everything else
defined in the class body?
On Jul 27, 2015 6:52 PM, Brendan Eich bren...@mozilla.org wrote:

 Michael McGlothlin wrote:

 I'd rather that prop just match the object the method is actually
 attached to, regardless of the context of 'this', before continuing
 searching the tree. Familiar as its done that way in many languages,

 You mean static (applied to types, including fields in objects) languages?
 Those are not like JS in the critical sense that a free variable reference
 in a JS method, e.g.

 class C {
   m() { return x; }
   ...
 }

 should resolve per lexical scope, not per an implicit `this.` that may or
 may not apply, depending on whether 'x' in this = true.

 If you say it always means `this.x` then there's no way to refer to an
 outer lexical variable, x.

 So there has to be some prefix, if not `this.`, to distinguish.

 /be
 ___
 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

Re: Generalize do-expressions to statements in general?

[Matthew Robb]

Just wanted to say I was playing around with the idea of using parens as
block-expressions this morning and I REALLY like it. It doesn't feel like
an added feature at all it just seems natural since blocks don't normally
produce a value.

The questions I think that remain are:
1) return?
2) yield?


- Matthew Robb

On Fri, Jul 17, 2015 at 9:27 AM, Mark S. Miller erig...@google.com wrote:

 I don't see a conflict between return and being an expression language.

 Smalltalk and E both have return. In Scheme terms, this is simply
 call-with-escape-continuation. Gedanken again was probably the first to
 have this right with their escape construct, which E borrowed. E's method
 syntax desugars into a more primitive method syntax plus a top level escape
 form defining an escape continuation. E's return desugars into calling the
 escape continuation.

 The problem with return is orthogonal -- that we chose to define arrow
 functions so that are their own return point, rather that having return be
 TCP to the enclosing method. In escape continuation terms, we made the
 mistake of shadowing the outer escape continuation binding. But making JS
 into an expression language would not make this worse.



 On Fri, Jul 17, 2015 at 2:14 AM, Andreas Rossberg rossb...@google.com
 wrote:

 On 16 July 2015 at 17:29, Mark S. Miller erig...@google.com wrote:

 When simply generating simple JS code from something else, this
 restriction is a perpetual but minor annoyance.


 Indeed, one motivation for do-expressions is better support for compilers
 targeting JS. And for some of those, not being able to mix statements and
 expressions, not having try inside expressions, and not having support for
 nested bindings, can be very tough, because it prevents compositional
 translation.


 By itself, I would agree that this annoyance is not important enough to
 add a new feature. However, if rather than adding a feature, we can
 explain the change as removing a restriction, then JS would get both
 simpler and more powerful at the same time. Ideally, the test would be
 whether, when explaining the less restrictive JS to a new programmer not
 familiar with statement languages, this change results in one less thing to
 explain rather than one more.


 I doubt that will work, because there still will be plenty of artefacts
 and irregularities of a statement language that they will have to
 understand. Pretending it's an expression language will rather cause more
 confusion than less, because it isn't (for one, you can't get rid of the
 'return' statement).

 /Andreas




 --
 Cheers,
 --MarkM

 ___
 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

Re: for statement with index and value

[Matthew Robb]

Why not use the new meta syntax?

for (let value of values) {
  console.log(for.index);
}


- Matthew Robb

On Tue, Jul 14, 2015 at 7:45 AM, Jonathan Bond-Caron 
jbo...@gdesolutions.com wrote:

 On Mon Jul 13 10:22 PM, Kevin Smith wrote:

  Destructuring is here to help:
 
  for (let [index, value] of [1, 2, 3].entries())
  console.log(index + :  + value)
 
  The entries method returns an iterator of [index, value] pairs.
 

 Can't there be a 'key iterator' syntax?

 for (let value, index of [1, 2, 3])
  console.log(index + :  + value)

 let value = itOfValues.next().value;
 let index= itOfKeys.next().value;

 - An array has an implicit 'key iterator' cause there's a key for each
 value.
 - Everything else has a 'keyIteratorFrom0ToInifinity'

 So you have a 'value iterator' and a 'key iterator' for each thing on the
 RHS.
 Doesn't seem like much of an issue, engines just need a
 keyIteratorFrom0ToInifinity for non-array things cases.


 ___
 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

Re: Generalize do-expressions to statements in general?

[Matthew Robb]

The only gripes I have with do expressions is the inability to specify the
value produced in an obvious and uniform way, also are do expressions
capable of being labelled?


- Matthew Robb

On Tue, Jul 14, 2015 at 3:31 AM, Andreas Rossberg rossb...@google.com
wrote:

 I don't see why you need parens at all, see my previous post. But I
 wouldn't make the do-less forms the base syntax,; rather, only short-hands
 for the general thing. In particular, because the ability to have an actual
 block inside an expression is one primary motivation for having
 do-expressions in the first place.

 ...Ah, it's 2015, and we still have to come up with ways to overcome the
 archaic statement/expression distinction from the stone ages. :)

 /Andreas


 On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:

 Interesting. Got me thinking. Here's an alternate proposal I'll call do
 expressions without the 'do'.

 At 
 https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
 we have the syntax of the expression statement. Ignoring sloppy let
 nonsense, this says that an expression statement cannot begin with {,
 function, or class.

 At 
 https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
 are the legal ES6 statements. Note that most of these begin with a keyword
 that cannot possibly be legal at the beginning of an expression. Therefore,
 adding all these initial-statement-keywords to the list of things that
 cannot begin an expression statement would break nothing. They already
 cannot begin an expression statement.

 With the expression statement prohibition in place, now we can allow all
 these forms to be expressions. As with {, function, or class, if you
 want to state such an expression in expression-statement position, surround
 it with parens.

 Because all these new forms will look bizarre and confusing, at least at
 first, let's say these always need surrounding parens to be expressions. I
 think that would help minimize confusion.

 If we do this, the oddest duck is {, since it begins an object literal
 expression. This proposal gives us no straightforward way to express an
 block expression. function and class are less odd, since their existing
 expression forms mean what you almost might expect by this new rule -- even
 though they are initial-declaration-keywords rather than
 initial-statement-keywords.

 The remaining initial-declaration-keywords are let and const. We
 already made let insane regarding these issues in sloppy mode, so I'm
 going to ignore that. But let's consider const and strict let. These
 already cannot appear at the beginning of an expression, so it would not
 break anything to add them to the prohibition list for the beginning of
 expression statements.

 No current expression can add any binding to the scope in which the
 expression appears. Let's examine the consequences of having parens --
 rather than containing a {-block to create a nested scope with a value
 (which would conflict with object literals), instead simply define a
 block-like nested scope with a value. This would allow declarations and
 statements within the parens, much like the current do proposal. It would
 even be consistent enough with the existing semantics of paren-surrounded
 function and class expressions: Someone who sees these as a function or
 class declaration within its own nested scope, whose value was the value
 being declared, would rarely be surprised by the subtle difference between
 that story and the current semantics.

 Having parens accept a list of declarations and statements rather than
 just an expressions seems like a radical change that must break something,
 but I can't find a problem. Am I missing something?

 Examples inline:



 On Mon, Jul 13, 2015 at 5:47 PM, Isiah Meadows impinb...@gmail.com
 wrote:

 I was reading a recent thread
 https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value where
 do-expressions simplified a common try-catch use case, and I was wondering
 if `do` could be simplified to an expression? It would allow for this to be
 solved very easily, but also add a lot more flexibility in this proposal,
 as well as avoiding some ugly nested braces.

 I know it would cause an ambiguity with `do-while` loops, but that could
 be resolved with a single token lookahead of if the next token is the
 keyword `while`, then the block body is the body of a do-while loop, else
 it is the body of the block statement in a `do` expression.

 As for the EBNF, do-expressions could be parsed with a goal symbol of
 either `+While` or `-While`, with do-while statements spec-wise effectively
 being treated as do-expressions without an init part run repetitively, but
 mandated to be statements.

 ```js
 // Do expression
 let foo = do {
   foo(0)
 };


 let foo = (foo(0));

 This seems as broken as the original. In both cases, unless I'm missing
 something, this is a TDZ violation when the right

Instance bound class methods

[Matthew Robb]

Are there any proposals or any discussions around solving the problem of
instance bound class methods with some sugar?

There are examples of people doing things like this:
https://github.com/reactjs/react-future/blob/master/01%20-%20Core/01%20-%20Classes.js#L31

My proposal would be to extend method shorthand syntax to support the arrow:

```
class A extends React.Component {
  handleClick(event)= {
 ...
  }
}
```
Which would be sugar for:
```
class A extends React.Component {
  handleClick = (event)= {
 ...
  }
}
```
- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Instance bound class methods

[Matthew Robb]

What I'd really like to have in the language is the ability to store a
property access into a single binding:

```
let someObj = { doStuff(){} };

let doStuff = #someObj.doStuff;

doStuff();
```
Treated as:
```
let someObj = { doStuff(){} };

someObj.doStuff();
```
- works with any property access
- could help simplify some existing code bases:
https://github.com/polymer/observe-js#path-objects
- for functions it would allow call/apply or bind to still work if needed

Now I realize this feature is more than syntactic sugar and would have to
work more like expression pointers but I can't see how the machinery of
this would need to be that much different than something like module
bindings.



- Matthew Robb

On Mon, Jul 13, 2015 at 11:02 AM, Brendan Eich bren...@mozilla.org wrote:

 You're counting on the property assignment being moved into the
 constructor, where `this` is bound. In a class body in ES6 (without
 property assignment extension), especially in the top level where method
 defintiions go, `this` isn't obviously bound to the newly constructed
 instance.

 Ok, that's kind of a nit, or an observation. No worries.

 Bigger question is what we want: method per instance allocation cost,
 which what you did imposes? Or something that can be more efficiently
 implemented, such as what Strong/SoundScript proposes (last I looked). The
 latter is what Java and C++ do. Then the trick is enabling first-class
 function extraction from method, which is a pay-for-what-you-ask-for
 alternative to allocation per method per constructed instance.

 /be

 Matthew Robb wrote:

 Are there any proposals or any discussions around solving the problem of
 instance bound class methods with some sugar?

 There are examples of people doing things like this:
 https://github.com/reactjs/react-future/blob/master/01%20-%20Core/01%20-%20Classes.js#L31

 My proposal would be to extend method shorthand syntax to support the
 arrow:

 ```
 class A extends React.Component {
   handleClick(event)= {
  ...
   }
 }
 ```
 Which would be sugar for:
 ```
 class A extends React.Component {
   handleClick = (event)= {
  ...
   }
 }
 ```
 - Matthew Robb
 ___
 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

Re: revive let blocks

[Matthew Robb]

I feel like this would just get confused with object destructuring.
On Jun 25, 2015 5:17 PM, Herby Vojčík he...@mailbox.sk wrote:

 Hello!

 Though this is a kind of syntax is probably macroable, interesting idea
 appeared in my mind regarding let blocks, so I would show it here, maybe it
 can actually be interesting for others as well.


 The idea is to use existing let statement and extending it so one can
 include { ... code ... } block in place of last assignment. Hold on for a
 while: this form can merge with do-expressions by using 'let', not 'do' as
 the keyword:

   let a = 4, b = 3; // normal let
   let { throw new Error(Throw in an expression); } // let-expression
   let a = 4, b = 3, { a + b } // let-expression with own local lets

 The third form is more or less the let-block from the PoV of reader, even
 if in fact is a new do-expression using let keyword with some let-assigment
 local to that block happening before.

 I see a 'problem' that I can only distinguish if it is a let-statement or
 let-expression at the end of it, but afaict it does not pose any real
 gotchas for the compiler - it accumulates the assignment and at the either
 make them let-statement and use them for the rest of enclosing block or
 makes it let-expression and use them only locally.

 Herby

 Kyle Simpson wrote:

 Just to wrap this thread up, quoting myself from another thread:

 In any case, I won't push my proposal anymore.

 

 But for posterity sake, wanted to make one last comment as to why the
 various suggestions for IIFE's and arrow expressions are inappropriate for
 the task: they change (hijack) the behavior of `return`, `break`, and
 `continue`. A standalone block like `{ let x = 2; .. }` or `let (x = 2) {
 .. }` can be placed anywhere, inside a function, loop, etc, and not hijack
 these types of statements.

 I'll be sticking with:

 ```js
 { let x = 42;

  console.log(The meaning of JS: , x);

 }
 ```

 Appreciate the various thoughtful responses.
 ___
 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

Re: revive let blocks

[Matthew Robb]

On Thu, Jun 25, 2015 at 6:20 PM, Brendan Eich bren...@mozilla.org wrote:

 I think do expressions are go for ES7 but they need re-championing, and
 implementation. I'll stir the pot.


​Might this include something like the following form?: ` do(let x = 1) {}
`​. Seems like that might satisfy Kyle's original request.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Matthew Robb]

Yes, please. Also if like to take issue with everyone who prefers email
clients for the following reason: it's easier to allow people who want to
keep using email to do so while enabling a richer and more aggressive
experience for those who want it than it is the other way around
On Jun 19, 2015 5:21 PM, // ravi ravi-li...@g8o.net wrote:

 On Jun 19, 2015, at 5:12 PM, C. Scott Ananian ecmascr...@cscott.net
 wrote:
 
  No, thank you.​
  Email clients are the ultimate forum aggregators.


 +1 on “No, thank you. Email works, email has are full-featured clients,
 do not force browser use, etc, etc.

 —ravi


   --scott

 ___
 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

Re: Example of real world usage of function bind syntax

[Matthew Robb]

​I am extremely excited about this extension proposal as well but:​

On Thu, Jun 11, 2015 at 10:31 AM, Kevin Smith zenpars...@gmail.com wrote:

 I've been considering reducing the scope of the proposal, focusing on the
 immediate apply aspect of the operator, while leaving open the option of
 adding the other features at a later time.  Specifically,

 - Remove the prefix form of the operator.
 - Restrict the syntax such that an argument list is required after the
 right operand.


​​I would be significantly less excited about it if this happens. The
ability to pass around lightly bound references to methods is a big deal
imo and a large part of the value in this proposal.

Like you said it doesn't matter what train it gets on, if the new release
cadence for ES works as we all hope then it should ultimately stop
mattering what release a feature is officially spec'd in. Ideally once a
feature reaches candidate stage it should be considered ready, right?


- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Example of real world usage of function bind syntax

[Matthew Robb]

@Sebastian It would be interesting to explore having a defined method of
deprecation for features. Basically say this bind syntax is being dropped,
I'd like Babel to be able to transpile all of my SOURCE files to remove
it's usage. Has anything like this been discussed before?


- Matthew Robb

On Thu, Jun 11, 2015 at 11:28 AM, Domenic Denicola d...@domenic.me wrote:

 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Matthew Robb

  ​​I would be significantly less excited about it if this happens. The
 ability to pass around lightly bound references to methods is a big deal
 imo and a large part of the value in this proposal.

 Definitely agree. Being able to do `foo.map(::this.bar)` is really great,
 and even `const extracted = ::foo.bar` is nothing to sneeze at.

 I know there's a thread on the issue tracker where a few vocal voices are
 complaining that they want partial application syntax and bikeshedding on
 various operator forms related to that, but I don't think that should
 discourage the excellent benefits that you're giving to everyone but those
 few.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Example of real world usage of function bind syntax

[Matthew Robb]

On Thu, Jun 11, 2015 at 11:37 AM, Sebastian McKenzie seb...@gmail.com
wrote:

 then you’ve already committed a sin.


​I guess my point is that I think it's a GOOD thing that developers are
taking the risk to try these features out in production and rather than
focusing on a way to better discourage such usage it may be better in the
long run to find a way to make it less risky.

The reality is that even though a feature is not in spec and even if it's
eventually dropped for consideration the transpiler is still going to work
because it's target is ES5. I think if a team decides they want to use an
experimental feature that it SHOULD NOT be discouraged but made clear that
support may eventually land on them and/or the maintainer of the plugin for
said feature or a plugin that can be used to assist in removal of the
feature if the need arises.​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Example of real world usage of function bind syntax

[Matthew Robb]

On Thu, Jun 11, 2015 at 11:43 AM, Matthew Robb matthewwr...@gmail.com
wrote:

 or the maintainer of the plugin for said feature


​To expand on this: I would also suggest that all experimental features be
implemented as plugins even if doing so will cause a slow down of builds
for users of the feature. I would go so far as to say the only features
that should be implemented outside of plugins should be stage 1 and higher.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Example of real world usage of function bind syntax

[Matthew Robb]

Here's a cool trick I found using this bind syntax today: Babel REPL
http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falseplayground=falsecode=class%20Foo%20%7B%0A%20%20bar%20%3D%20%3A%3Athis.bar%3B%0A%20%20bar()%7B%20%20%7D%0A%7D

But it lead me to think that class methods could have `::` prefixed onto
them to suggest that they be lightly bound method references:

class X {
  ::Y() {  }
}


- Matthew Robb

On Thu, Jun 11, 2015 at 11:56 AM, Jordan Harband ljh...@gmail.com wrote:

 I find the call form of the operator (`a::b()`) very useful on its own.

 However, I think the main question is, will shipping the prefixed bind or
 prefixed call forms of the operator (`::a.b`, `::a.b()`), and/or the bind
 form of the operator (`a::b`), definitely preclude future extension
 with partial application, etc, or can those still be worked in somehow? If
 there's a way to include all four forms and leave open the future
 possibility of extension, I think, as Domenic points out, that we would see
 a lot of value from the bind and prefix forms as well.


 On Thursday, June 11, 2015, Domenic Denicola d...@domenic.me wrote:

 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Matthew Robb

  ​​I would be significantly less excited about it if this happens. The
 ability to pass around lightly bound references to methods is a big deal
 imo and a large part of the value in this proposal.

 Definitely agree. Being able to do `foo.map(::this.bar)` is really great,
 and even `const extracted = ::foo.bar` is nothing to sneeze at.

 I know there's a thread on the issue tracker where a few vocal voices are
 complaining that they want partial application syntax and bikeshedding on
 various operator forms related to that, but I don't think that should
 discourage the excellent benefits that you're giving to everyone but those
 few.
 ___
 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

Re: Look-behind proposal

[Matthew Robb]

This thread is a cool example of why this list is still do important. +1 to
all of it!
On Jun 9, 2015 4:20 AM, Sebastian Zartner sebastianzart...@gmail.com
wrote:

 Thank you Brendan for picking this up!
 Nozomu, Brendan, please let me know if I can be of any help.

 Sebastian

 On 8 June 2015 at 18:47, Brendan Eich bren...@mozilla.org wrote:
  I will do it if no one else steps up by 10pm tonight PDT.
 
  Thank you to Nozomu Katō for writing it up!
 
  /be
 
 
  Sebastian Zartner wrote:
 
  So the question is, how to recruit a TC39 member? Through this list? Is
 it
  possible to become a member as a private person?
 ___
 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

Re: Promise sub-class: super((resolve, reject) = this) ?

[Matthew Robb]

It seems like, at least in the case with Promise, it could be solved also
by having the this binding of the executor bound to the promise or have the
promise object passed into the executor as a third argument maybe?
On Jun 2, 2015 10:38 PM, Brendan Eich bren...@mozilla.org wrote:

 With best intentions I must say that you are overreacting. The
 subject-line code (h/t Mark Miller for pointing me at it!) in context of
 the superclass constructor uses `this` before `super` has returned. That's
 a no-no for pretty-good reason.

 If you have a better alternative design, we needed it last month. As
 things stand, this is a thing to learn, with a workaround. What's the big
 deal?

 /be


 Matthew Robb wrote:

 If I thought I could make any money then I would most definitely bet that
 the changes made to classes that are at the root of this problem will be
 the undoing of es classes and I find myself feeling more and more like
 avoiding them is the easiest thing to do.

 This use-case is a perfect example of something that is EXTREMELY
 unexpected which is funny because the changes are supposed to be supporting
 subclassing of built-ins.

 Very disheartened :(


 - Matthew Robb

 On Tue, Jun 2, 2015 at 6:43 PM, Domenic Denicola d...@domenic.me mailto:
 d...@domenic.me wrote:

 Hmm I am pretty sure Babel et al. are correct here in not allowing
 this. The super call needs to *finish* before you can use `this`.
 Chrome also works this way.

 The correct workaround is

 ```js
 let resolve, reject;
 super((a, b) = {
   resolve = a;
   reject = b;
 });

 // use this
 ```


 ___
 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

Promise sub-class: super((resolve, reject) = this) ?

[Matthew Robb]

I was trying to demonstrate a simple method of exposing resolve and reject
functions to someone and noticed in Babel at least you cannot do this. It
seems as though in this case when the arrow function is called it will have
been AFTER the call to super.

Can someone help me understand what's going on here?

- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise sub-class: super((resolve, reject) = this) ?

[Matthew Robb]

If I thought I could make any money then I would most definitely bet that
the changes made to classes that are at the root of this problem will be
the undoing of es classes and I find myself feeling more and more like
avoiding them is the easiest thing to do.

This use-case is a perfect example of something that is EXTREMELY
unexpected which is funny because the changes are supposed to be supporting
subclassing of built-ins.

Very disheartened :(


- Matthew Robb

On Tue, Jun 2, 2015 at 6:43 PM, Domenic Denicola d...@domenic.me wrote:

 Hmm I am pretty sure Babel et al. are correct here in not allowing this.
 The super call needs to *finish* before you can use `this`. Chrome also
 works this way.

 The correct workaround is

 ```js
 let resolve, reject;
 super((a, b) = {
   resolve = a;
   reject = b;
 });

 // use this
 ```


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Matthew Robb]

It would be great if the web app manifest included the dependency graph for
the app. Something like the depCache in system js.
On Apr 23, 2015 8:03 PM, Matthew Phillips matt...@bitovi.com wrote:

 I think the issue of round-trips is a red-herring. I spent some effort
 trying to optimize an es6 loader with caching in indexeddb and even that
 did not help much.  I think what caridy said earlier is likely the biggest
 issue, processing a large number of Promises.

 On Thu, Apr 23, 2015 at 7:55 PM, John Barton johnjbar...@google.com
 wrote:

 Sorry, but what I read was not an explanation but rather a hope that
 HTTP/2 would magically solve this problem.  I'm all for HTTP/2 solving
 this. But so far I've not heard or read anything to back up the idea.

 Will HTTP/2 make multiple round trips, one for each level of the
 dependency tree, competitive with pre-bundling? If not, then we will have
 to send dependency info to the client or cache info to the server or
 bundle. Or there is some magic as yet unexplained?

 jjb

 On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me wrote:

  Indeed, there is no built-in facility for bundling since as explained
 in this thread that will actually slow down your performance, and there’s
 no desire to include an antipattern in the language.



 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
 Of *Eric B
 *Sent:* Thursday, April 23, 2015 10:25
 *To:* Frankie Bagnardi; Matthew Phillips
 *Cc:* es-discuss
 *Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
 level-by-level?



 So just to clarify, when browsers support es6 modules we will still need
 some extra library to bundle the modules?  This would mean es6 modules are
 only a syntactical addition and not something functional?



 On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi f.bagna...@gmail.com
 wrote:

  Matthew, there are already tools for es6 modules + bundling (e.g.
 babel + webpack), or converting es6 modules to AMD (e.g. babel
 https://babeljs.io/docs/usage/modules/).







 On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com
 wrote:


  Can you clarify what you mean about bundling? Unless I've missed
 something, the ES6 module system does not have a story for bundling at all.
 Of course formats can be invented in userland but I'm not sure that they
 are any easier to implement than say AMD's.  I might have missed something
 though, looking forward to your reply.


 ___
 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





 --
 Bitovi
 Development | Design | Training | Open Source

 ___
 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

Re: Existential Operator / Null Propagation Operator

[Matthew Robb]

On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich bren...@mozilla.org wrote:

 Did you keep backward compatibility? `x?.1:y` must continue to work.


​This is why I suggested a leading operator (`?a.?b()`) because it seems
like it would have the least potential for conflict with existing valid
syntax​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to fix the `class` keyword

[Matthew Robb]

I have to be honest, there is ONE sticky point to the way classes work
right now. Why have them throw when called without `new`? The way you
traditionally guard against needing to rewrite call sites later would be to
check if this instanceof Constructor in the constructor. I believe this is
now impossible, correct?


- Matthew Robb

On Wed, Mar 4, 2015 at 12:33 PM, Dmitry Soshnikov 
dmitry.soshni...@gmail.com wrote:

 There is a trap one could fall into, after reading one classic or even
 authoritive book. After that it might seem one understood the essence of
 everything.

 For fairness, there were couple of valid points noticed:
 composition/aggregation (will be achieved, and already now can be, by
 mixins), and, probably, that you'll have to refactor call sites if you
 decide to switch to the raw factory (that's why eg Python chose to
 instantiate without 'new' keyword).

 Other than that, yes, factory is just a desugarred class pattern, and yes,
 sugar matters if you want to design a practical language. In case of
 class-based code reuse, prototypes were also desugarred version of it
 (that's why JS at some point was unexplained, and as a result made it
 harder to be practical quicker). Eg in my class I give prototypes as an
 advanced topic now, since it's just an implementation detail (the same
 again as in Python, which is also delegation-based).

 The most valuable advice would be from Eric Arvidsson - just to design
 your language (likely, to be a compiler writer is easier nowadays), and
 exactly there you'll see how sugar matters.

 Dmitry


 On Wednesday, March 4, 2015, Eric Elliott e...@paralleldrive.com wrote:


 I've already posted this on my Medium blog here:
 https://medium.com/@_ericelliott/how-to-fix-the-es6-class-keyword-2d42bb3f4caf

 It seems inevitable that the `*class*` keyword in JavaScript is going to
 catch on, but that’s a problem because it’s fundamentally broken in many
 ways.

 Now that it’s out there and people are using it, it seems like the only
 logical way forward is to *try to make it better for everybody*.

 In JavaScript, *any function can instantiate and return objects.* When
 you do so without a constructor, it’s called a *factory function*. The
 new `*class*` syntax *can’t compete with the power and flexibility of
 factories* — specifically stamps, and object pools are not the only
 factory use-case.

 There is a whole section on object construction in the GoF “Design
 Patterns” book
 http://www.amazon.com/gp/product/0201633612?ie=UTF8camp=213733creative=393185creativeASIN=0201633612linkCode=shrtag=eejs-20linkId=XXUP5DXMFH5VS2UI
  which
 exist only to get around the limitations of constructors and classes.

 See also: Three Different Kinds of Prototypal OO.
 http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/

 The bottom line: *Class doesn’t give you any power* that isn’t already
 supplied by *factory functions* and the *prototypal OO* built into the
 language. All you’re doing when you create a class is opting into a *less
 powerfull, less flexible mechanism* and *a whole lot of pitfalls and
 pain.*
 https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3

 Is there any hope that the `*class*` keyword will ever be useful?
 *Maybe.*
 Why should we bother?


 Why don’t we just create a lint rule and move on?

 *The `class` keyword is creating a rift* in the JavaScript community. I
 for one have plans to create an ESLint config that prohibits `*class*`
 and share it as far and as wide as I can — and since I’m building a
 community of JavaScript developers that currently includes ~40,000 people,
 that’s far enough to have an impact.

 *Classes could be useful*. What if we want to build abstractions on top
 of it? What if we want to do more things in the language itself that could
 benefit with `*class*` integration (such as built-in *traits*)?

 *We could make these changes opt-in* by adding config to the class
 itself. That would prevent breaking changes and hopefully make the whole
 community happy. As it stands, we're just making people with classical
 inheritance backgrounds happy -- *at least until they fall into one of
 the many pitfalls ahead of them.*

 *Shouldn’t the entire JavaScript community benefit from `class`?*
 *How to Fix `class`*

1. *Make class inheritance compositional* similar to the way stamps
are composed.

 http://chimera.labs.oreilly.com/books/123400262/ch03.html#prototypal_inheritance_with_stamps
  In
other words, change the behavior of `*extend*`, or *deprecate
`extend`* and replace it with something like a *`compose` keyword* that
can *compose any number of classes.*
2. *Deprecate `new`. *`*new*` violates both the *substitution
principle* and the *open / closed principle*. The `*new*` keyword is
destructive because *it adds zero value to the language*, and it *couples
all callers to the details of object instantiation*. If you start

Re: How to fix the `class` keyword

[Matthew Robb]

Making the following two things no longer interchangeable completely breaks
my mental model for JS:
```
var x = new X;
```
and
```
var x = {}; X.call(x);
```

Yes the above is useless for built in types but it's very widely employed
in user code, libraries, and frameworks. Making the above no longer true is
a huge mistake imo and it changes the language in a fundamental way. We
used to have objects and objects that you could call (functions). Now we
have objects, functions, and something else... For what?

I thought the idea of max/min classes was to stay as true to the OOP
patterns used today as possible? So shouldn't the question be reversed and
classes should work like sugar for functions intended for use as
constructors instead of breaking that model and requiring justification in
a later draft to restore expected behavior?


- Matthew Robb

On Wed, Mar 4, 2015 at 2:03 PM, Matthew Robb matthewwr...@gmail.com wrote:


 On Wed, Mar 4, 2015 at 1:47 PM, Kevin Smith zenpars...@gmail.com wrote:

 Allowing the user to specify the call behavior for class constructors
 is something to consider for post-ES6.


 ​Unfortunately, based on this kind of logic (not the first I have seen it
 on here) I would ask that we stop calling ES6 classes simple sugar on
 existing conventions. This is a major breaking difference in the most
 surface-y aspect of classes and how they are used in people's code. ​



 - Matthew Robb

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to fix the `class` keyword

[Matthew Robb]

On Wed, Mar 4, 2015 at 1:47 PM, Kevin Smith zenpars...@gmail.com wrote:

 Allowing the user to specify the call behavior for class constructors is
 something to consider for post-ES6.


​Unfortunately, based on this kind of logic (not the first I have seen it
on here) I would ask that we stop calling ES6 classes simple sugar on
existing conventions. This is a major breaking difference in the most
surface-y aspect of classes and how they are used in people's code. ​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to fix the `class` keyword

[Matthew Robb]

On Wed, Mar 4, 2015 at 2:13 PM, Matthew Robb matthewwr...@gmail.com wrote:

 var x = {}; X.call(x);


​Sorry this should have read:
```
var x = Object.create(X.prototype); X.call(x);
```​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to fix the `class` keyword

[Matthew Robb]

On Wed, Mar 4, 2015 at 2:29 PM, Kevin Smith zenpars...@gmail.com wrote:

 In order to allow subclassing as built-ins, we had to opt for the builtin
 model.


​Help me make sure I am understanding correctly. This decision doe​s not
help in making DOM subclassable. It doesn't simply or easily integrate into
all the existing and somewhat common OOP patterns in user land. What
built-ins are we talking about then? The decision to fork things here seems
MOSTLY motivated by a desire to support `class extends Array{}`... Am I
crazy? If not There had to be a better way.

On the issue of calling class constructors, I would AT LEAST have preferred
implicit new on all calls to class constructors. Sure you might get extra
allocation weight but the way it stands now seems like it could only lead
to errors in people's assumptions... Assumptions people have built up in
their experience using the language and that are not only safe TODAY but
considered best practice.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function name property

[Matthew Robb]

On Thu, Feb 26, 2015 at 11:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:

 We may have a universal way for functions to self reference themselves i
 post ES6.


​+1 this​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function name property

[Matthew Robb]

On Wed, Feb 25, 2015 at 11:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:

 The automatically provided ‘name’ property of function objects has the
 attributes writable: false, configurable true. That means that its value
 can be modified using Object.defineProperty or deleted using the delete
 operator.  You just can’t modify it using the assignment (=) operator.


​My mistake, rather than check the spec I tried it in Chrome's console and
the property descriptor was configurable: false.​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Additional Meta Properties for ES7

[Matthew Robb]

I am positive that there will be good reasons I am just curious what they
might be, why not: `function(){ function(); }`


- Matthew Robb

On Thu, Feb 26, 2015 at 8:00 PM, Tom Schuster t...@schuster.me wrote:

 I think it's easier to convey the message to never use callee instead
 use function.self.
 On Feb 27, 2015 1:52 AM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:

 ((n)=n1? n*function.callee(n-1) : 1)





 On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote:

  Can you show an example of how callee is used with a fat arrow function?
 
  (()={alert(callee);})()
 
  Thanks.
 
  On 2/26/15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
  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
 
  I've added this to the agenda for next months TC39 meeting but
 pre-meeting
  discussion is always welcomed right here.
 
  Allen
 
 
 
 
  --
  Garrett
  @xkit
  ChordCycles.com
  garretts.github.io
 

 ___
 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

Re: Proposal: Additional Meta Properties for ES7

[Matthew Robb]

Or the following three forms would be great:

// normal form
function();
// or
function.invoke();

// additionally
function.call();
function.apply();


- Matthew Robb

On Thu, Feb 26, 2015 at 9:29 PM, Matthew Robb matthewwr...@gmail.com
wrote:

 I am positive that there will be good reasons I am just curious what they
 might be, why not: `function(){ function(); }`


 - Matthew Robb

 On Thu, Feb 26, 2015 at 8:00 PM, Tom Schuster t...@schuster.me wrote:

 I think it's easier to convey the message to never use callee instead
 use function.self.
 On Feb 27, 2015 1:52 AM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:

 ((n)=n1? n*function.callee(n-1) : 1)





 On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote:

  Can you show an example of how callee is used with a fat arrow
 function?
 
  (()={alert(callee);})()
 
  Thanks.
 
  On 2/26/15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
  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
 
  I've added this to the agenda for next months TC39 meeting but
 pre-meeting
  discussion is always welcomed right here.
 
  Allen
 
 
 
 
  --
  Garrett
  @xkit
  ChordCycles.com
  garretts.github.io
 

 ___
 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

Re: Re-export default?

[Matthew Robb]

​Just curious if this meets the use cases being discussed here, @caridy
@jason ?
​

On Thu, Feb 19, 2015 at 9:22 AM, Matthew Robb matthewwr...@gmail.com
wrote:

 import a from a;
 import b from b;

 export { a, b };





- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re-export default?

[Matthew Robb]

Why not simply

import a from a;
import b from b;

export { a, b };
On Feb 19, 2015 8:18 AM, Jason Kuhrt jasonku...@me.com wrote:

 I hear the verdict but not any substantial rationale; why is it
 “confusing”?’

 @caridy regarding your examples for JS2016 wouldn’t this

 export default from “foo”;

 just re-export one module’s default as another module’s default, right?

 In my use-case, in order to map n-number of default-export functions to
 named-export functions I would have to do this ad-infinitum:

 export {default as a} from “./a”
 export {default as b} from “./b”
 export {default as c} from “./c”
 export {default as d} from “./d”
 export {default as e} from “./e”
 ...

 I’m not saying my syntax for my use-case is amazing, I’m just working
 within the confines of JS. Other languages such as Go have their own
 interesting approaches to modules that we cannot really consider in JS due
 to needing a high level of semantic mapping to legacy CJS Modules.



 On Feb 19, 2015, at 1:31 AM, caridy car...@gmail.com wrote:

 Yes, that syntax is incorrect and confusing.

 There was an overside from our end to provide a way to re-export only the
 default export from another module, and this is something we plan to
 revisit for ES7/2016. Probably something like this:

  `export default from “foo”;`

 this is just sugar for:

  `export {default} from “foo”;`

 which is perfectly supported in ES6, including the ability to rename it:

  `export {default as something} from “foo”;`

 /caridy

 On Feb 18, 2015, at 9:08 PM, Jason Kuhrt jasonku...@me.com wrote:

 I was prompted to bring this issue to es-discuss.

 https://github.com/babel/babel/issues/826

 It is my confusion about why this syntax does not work:

 export foo from ‘./foo'


 More details are in the issue but the gist is that sometimes it is
 actually quite handy to export just defaults internally and then re-export
 thing as a “bag” of named exports. This is not currently “easy”. I assume
 this was discussed/considered. I’d be curious what the rationale was.

 Thanks!
 Jason
 ___
 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

Re: Why is export default var a = 1; invalid syntax?

[Matthew Robb]

I guess the take away here is that the default export is NOT a shared
binding, correct?


- Matthew Robb

On Tue, Feb 17, 2015 at 5:38 PM, caridy car...@gmail.com wrote:

 Jesse, you can do:

 `export default class Foo extends Backbone {}`

 in case you want to reference to the exported class in the body of the
 module, or you can do:

 `export default class extends Backbone {}`

 /caridy

  On Feb 17, 2015, at 4:47 PM, Jesse McCarthy 
 es-discuss-2015...@jessemccarthy.net wrote:
 
  Re:
 https://esdiscuss.org/topic/why-is-export-default-var-a-1-invalid-syntax
 
  I find myself wanting to do this kind of thing with a function returned
 from a function, e.g. when using Backbone, and it seems silly that I can't:
 
  export default var Klass = Backbone.Model.extend();
  Klass.prototype.whatever = whatever;
  // ...
 
  For that use case will the following be functionally identical? Any
 gotchas with circular dependencies or anything?
 
  A)
  var Klass = Backbone.Model.extend();
  Klass.prototype.whatever = whatever;
  export default Klass;
 
  B)
  var Klass = Backbone.Model.extend();
  Klass.prototype.whatever = whatever;
  export { Klass as default };
 
  C)
  var Klass = Backbone.Model.extend();
  export default Klass;
  Klass.prototype.whatever = whatever;
 
  D)
  var Klass = Backbone.Model.extend();
  export { Klass as default };
  Klass.prototype.whatever = whatever;
 
  If I was willing to use class syntax could I do this?
 
  export default class Klass extends Backbone.Model.extend();
  Klass.prototype.whatever = whatever;
 
 
  Glen Huang said:
  I think this is illegal, should be {a: a}
 
  Sorry, I'm probably missing something obvious, but what is this
 referring to?
 
  ___
  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

Re: about lightweight traits

[Matthew Robb]

When I brought this up my thoughts were to have the classes flattened to a
linear inheritance model. Yeah this means an ownProp copy from the
constructor for statics and the prototype for instance onto methods. That
might be a limitation but currently class syntax is javascript's nicest way
to describe behavior units.


- Matthew Robb

On Thu, Feb 12, 2015 at 12:32 PM, Sébastien Cevey seb.ce...@guardian.co.uk
wrote:

 I would agree.

 How would you use classes as traits -- are you talking about multiple
 inheritance? Or flattened to a linear inheritance model?

 On 12 February 2015 at 16:35, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

 Without going down full specification/implementation details, does anyone
 believe that classes should/could be used, in the future, as traits/mixins
 too?

 I find that an anty pattern.

 I think traits should be just plain objects with an initializer or some
 special object flagged as trait and I'd rather leave inheritance and
 classes features outside this future feature.

 Thoughts? Thanks!

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




 --
 Sébastien Cevey
 Software Developer

 --
 Visit theguardian.com. On your mobile and tablet, download the Guardian
 iPhone and Android apps theguardian.com/guardianapp and our tablet
 editions theguardian.com/editions.  Save up to 57% by subscribing to the
 Guardian and Observer - choose the papers you want and get full digital
 access.  Visit subscribe.theguardian.com

 This e-mail and all attachments are confidential and may also be
 privileged. If you are not the named recipient, please notify the sender
 and delete the e-mail and all attachments immediately. Do not disclose the
 contents to another person. You may not use the information for any
 purpose, or store, or copy, it in any way.  Guardian News  Media Limited
 is not liable for any computer viruses or other material transmitted with
 or as part of this e-mail. You should employ virus checking software.

 Guardian News  Media Limited is a member of Guardian Media Group plc. 
 Registered
 Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered
 in England Number 908396



 ___
 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

Re: JavaScript 2015?

[Matthew Robb]

Honestly though, to the largest portion of JavaScript developers, the least
surprising name would be `JavaScript 2.0`


- Matthew Robb

On Thu, Jan 22, 2015 at 4:25 PM, Domenic Denicola d...@domenic.me wrote:

 The spec is no longer called ES6. The marketing hasn’t really begun to
 educate the community about this yet, but the spec is called ES 2015.

 As for your concern about 2015 seeming old in 2016: **good**. In 2016,
 we’ll be publishing ES 2016, and ES 2015 will be missing a lot* of stuff
 that ES 2016 has!

 * hopefully.

 ___
 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

Re: Any news about the `module` element?

[Matthew Robb]

On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino car...@gmail.com wrote:

 what make you think this proposal implies blocking?


​I think he was reading your examples using require() and thinking you
were suggesting that the semantics would match.​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: how to delay interpolation of template strings?

[Matthew Robb]

I might be wrong and either way it's probably too ugly to be serious but
couldn't you, using a template tag, do something like the following:

var template = compile`
Hello ${first_name}
`;

template({ first_name: John });


- Matthew Robb

On Tue, Dec 16, 2014 at 10:26 AM, Domenic Denicola d...@domenic.me wrote:

  You want templates, which is something provided by many libraries
 (Handlebars, etc.). The language provides template strings as a syntactic
 feature.



 Templates and template strings are very different. Don’t be fooled by the
 name into thinking that templates are some sort of natural feature addition
 to template strings; they’re in fact a different concept altogether.



 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of 
 *Niloy
 Mondal
 *Sent:* Tuesday, December 16, 2014 06:48
 *To:* Andrea Giammarchi
 *Cc:* es-discuss@mozilla.org
 *Subject:* Re: how to delay interpolation of template strings?



 Can this be considered for a feature request? Provision in the language to
 dynamically construct template strings and interpolate them.



 On Tue, Dec 16, 2014 at 4:48 PM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

  irony ... I think you would need to evaluate the template string inline
 in order to interpolate its result ...



 OR



 you just go for this method which also works down to ES3 engine:

 https://gist.github.com/WebReflection/8f227532143e63649804



 Regards



 On Tue, Dec 16, 2014 at 10:01 AM, Niloy Mondal niloy.monda...@gmail.com
 wrote:

   Thanks, this would work.



 How can I construct a template string dynamically? Like reading the
 template from a file/database and then interpolate it.



 On Tue, Dec 16, 2014 at 2:29 PM, Claude Pache claude.pa...@gmail.com
 wrote:



  Le 16 déc. 2014 à 09:27, Niloy Mondal niloy.monda...@gmail.com a écrit
 :



 I want to define a template string using backquotes in a different file
 and then have it interpolated with actual values in a different file. How
 can I do it?





 Just enclose it in a function:



 ```javascript

function foo(a) {

 return `some template ${a}`

 }



 foo(bar) // will evaluate `some template ${bar}`

 ```



 —Claude



 ___
 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

Re: how to delay interpolation of template strings?

[Matthew Robb]

Actually, it would be cool if some sugar could be done for the example I
just did:

var template = compile`
Hello ${{first_name}}
`;

template({ first_name: John });


- Matthew Robb

On Tue, Dec 16, 2014 at 10:40 AM, Matthew Robb matthewwr...@gmail.com
wrote:

 I might be wrong and either way it's probably too ugly to be serious but
 couldn't you, using a template tag, do something like the following:

 var template = compile`
 Hello ${first_name}
 `;

 template({ first_name: John });


 - Matthew Robb

 On Tue, Dec 16, 2014 at 10:26 AM, Domenic Denicola d...@domenic.me wrote:

  You want templates, which is something provided by many libraries
 (Handlebars, etc.). The language provides template strings as a syntactic
 feature.



 Templates and template strings are very different. Don’t be fooled by the
 name into thinking that templates are some sort of natural feature addition
 to template strings; they’re in fact a different concept altogether.



 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of
 *Niloy Mondal
 *Sent:* Tuesday, December 16, 2014 06:48
 *To:* Andrea Giammarchi
 *Cc:* es-discuss@mozilla.org
 *Subject:* Re: how to delay interpolation of template strings?



 Can this be considered for a feature request? Provision in the language
 to dynamically construct template strings and interpolate them.



 On Tue, Dec 16, 2014 at 4:48 PM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

  irony ... I think you would need to evaluate the template string inline
 in order to interpolate its result ...



 OR



 you just go for this method which also works down to ES3 engine:

 https://gist.github.com/WebReflection/8f227532143e63649804



 Regards



 On Tue, Dec 16, 2014 at 10:01 AM, Niloy Mondal niloy.monda...@gmail.com
 wrote:

   Thanks, this would work.



 How can I construct a template string dynamically? Like reading the
 template from a file/database and then interpolate it.



 On Tue, Dec 16, 2014 at 2:29 PM, Claude Pache claude.pa...@gmail.com
 wrote:



  Le 16 déc. 2014 à 09:27, Niloy Mondal niloy.monda...@gmail.com a
 écrit :



 I want to define a template string using backquotes in a different file
 and then have it interpolated with actual values in a different file. How
 can I do it?





 Just enclose it in a function:



 ```javascript

function foo(a) {

 return `some template ${a}`

 }



 foo(bar) // will evaluate `some template ${bar}`

 ```



 —Claude



 ___
 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

Re: how to delay interpolation of template strings?

[Matthew Robb]

On Tue, Dec 16, 2014 at 10:48 AM, Domenic Denicola d...@domenic.me wrote:

 But, what are the semantics of ${{}} in general, without the `compile` tag?


​Well syntactically speaking I don't think it's valid right now, if it were
it would be an object literal but in my mind that is considerably less
useful than what COULD be done there. If you were to take my example and
simply remove the compile tag you'd end up with Hello first_name;​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: how to delay interpolation of template strings?

[Matthew Robb]

On Tue, Dec 16, 2014 at 12:03 PM, Claude Pache claude.pa...@gmail.com
wrote:

 I guess you want sugar for the following valid ES6 code?


​You're right, I must be crazy for wanting my code to be readable and
slightly resemble the syntax people have been using as defacto-standard for
years now. I, and I am sure the greater web dev community, much prefer new
language features to be completely foreign and difficult to make sense of
in relation to what's already being done.

I don't mean to be snarky about it (and I apologize, I mean no offense) but
sheesh... Aren't things like async-functions sugar for existing valid es6
code? Maybe it would be better if what gets passed to a template
tag-function is not, by default, the values from the local-bindings.
Perhaps there is a way to make template tags much more useful by allowing
the function to determine more about the semantics of the string.

Sometimes this list really does make me think I am crazy or something.

- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: dynamic synchronous import

[Matthew Robb]

Also you CAN potentially do something like this eventually:
```
(async function() {
var myMod = await System.import(my-mod);
})()
```


- Matthew Robb

On Sun, Sep 28, 2014 at 11:45 AM, Guy Bedford guybedf...@gmail.com wrote:

 On 28 September 2014 07:01, John Lenz concavel...@gmail.com wrote:

 I would like to see some way to preload everything, and be able to
 retrieve them synchronously, something like:

   System.loader.addNoAsync('...');  // throw if all imports aren't
 available already

 So that the script could be used during initial render. I understand that
 this would mean that the module would need to be parsed and executed
 synchronously. Forcing folks to never use any module for code that needs to
 be inline seems like a bad turn.


 I'm not sure what rendering behaviour is planned for script
 type=module, but I hope there would be a way to indicate when it should
 and shouldn't block rendering of the HTML page / HTML import.

 In terms of preloading, there are complete ways to do this through custom
 extensions.



 On Fri, Sep 26, 2014 at 1:44 PM, John Barton johnjbar...@google.com
 wrote:

 Theoretically you can use System.normalize() and System.get() to lookup
 a module by name synchronously. The normalize feature requires a referrer
 or address.

 Since browsers are determined to eliminate synchronous scripts, you may
 as well deal with the asynchronous System.import() and obnoxious promises
 stuff now and save yourself some pain later.

 jjb

 On Fri, Sep 26, 2014 at 9:40 AM, Konstantin Ikonnikov 
 ikokos...@gmail.com wrote:

 I don't want load module using http request. In my case module already
 defined and I want import it later when I get its name:

 ```js
 var moduleName = getModuleName();
 import { foo } from moduleName;

 // use foo
 ```



 2014-09-26 20:00 GMT+04:00 Marius Gundersen gunder...@gmail.com:

 And the reason you cannot import a module synchronously is that it
 would freeze the entire browser until the http request completes, which
 could be several seconds on a slow internet connection.

 If you want to import something dynamically you can do it using the
 API (to be finalized, I believe):

 ```js
 var moduleName = 'foo';
 Loader.import(moduleName).then(function(foo){
   //use foo here
 });
 ```

 Marius Gundersen

 On Fri, Sep 26, 2014 at 5:29 PM, John Barton johnjbar...@google.com
 wrote:

 no.

 On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov 
 ikokos...@gmail.com wrote:

 Can I import module dynamically, but synchronously? Example for
 common js

 ```js
 var moduleName = 'foo';
 var foo = require(moduleName);
 ```

 In es6 draft I found that ModuleSpecifier must be a StringLiteral
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports

 ___
 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



 ___
 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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Idea for Strawman: separate the core standard library itself into modules

[Matthew Robb]

This was originally a part of the modules design but was cut due to timing.
You can find what did exist on the topic here:
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard


- Matthew Robb

On Mon, Sep 22, 2014 at 7:53 AM, Isiah Meadows impinb...@gmail.com wrote:

 I know this will never happen until at least ES9 (and this is highly
 optimistic) because of compat issues, but I was thinking: would separating
 the core standard library into modules be a good idea?

 I have a repo containing my idea in a little more detail here (
 https://github.com/impinball/harmony-stdlib).

 I also have more than one idea as to how it could be, and I'm very open to
 suggestions and feedback.

 I know this would break a lot of backwards compatibility completely, so
 this is purely hypothetical, and I expect this to not have a realistic
 chance anytime soon.

 --
 Isiah Meadows

 ___
 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

Re: Idea for Strawman: separate the core standard library itself into modules

[Matthew Robb]

On Mon, Sep 22, 2014 at 8:17 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:

 Until modules are shipping in engines we will have to continue to add
 globals.


​Honestly, I think an interim solution makes the most sense. Perhaps as
simple as a single namespace for adding new standard lib functionality​ to.
Ideally this would be broken down into pseudo-modular objects. This would
both be easier to map to modules in the future, polyfill now, and lines up
better with existing code management practices.



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script -- .esm

[Matthew Robb]

Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript. I would think you could just as easily do `.jsm` but this also
suggests that files of this alternate should be served with a different
mime type such as `text/javascript-module` or something along those lines.


- Matthew Robb

On Wed, Sep 10, 2014 at 11:30 AM, John Barton johnjbar...@google.com
wrote:

 A couple of months ago I tried out the suggestion by Yehuda Katz to use
 import syntax with special module specifiers to mean parse-as-script, do
 evaluate but do not produce a module.  The implementation worked well and
 now I want to put a version of this idea into Traceur.

 As soon as I started I ran it issues with the name. Obviously legacy: is
 ambiguous. script: looks like a URL, which I suppose was intended, but
 then we get into URLs in URLs.  Furthermore, the URL scheme is very
 cumbersome with a filesystem, you have to have some side-table or algorithm
 to match URLs to directories or filenames.

 I implemented postfix ,script, but that sure looks like an extension.
 Which is exactly what the semantics are: a file with a different datatype
 needing different processing. So it seems to me that the most honest naming
 would be some thing like .ess.

 I would just implement that solution but I proposed a similar idea a while
 back to Traceur team I got a lot of pushback along the lines of JS is one
 language.  Since then several Traceur users have asked for support to a
 non .js extension for loading modules, to be able to separate existing JS
 code in .js files from new module code in files marked with a different
 extension. Within Traceur's (mostly es6) code we have resorted to implicit
 marking-by-directory (All code in src/node is script, not module) or with
 the wonderful extension of .module.js to mean all the other files are
 script, but this one is module.  So it's JS-is-one-language with two
 incompatible, unmentionable dialects ;-).

 Finally, naming modules as .js and ES6 Scripts as .ess has the weird
 result that ES5 scripts (in .js files) would be processed as ES6 modules.
 That seems dumb. So naming the new things, modules, with a new extension
 makes more sense.  .esm seems like a obvious choice.

 I know this may not seem to be the most exalted of topics for
 standardization but the current choice of post-pending '.js' has real
 consequences for developers. Please consider this issue.

 jjb



 On Mon, Jul 14, 2014 at 9:57 PM, Yehuda Katz wyc...@gmail.com wrote:

 You could imagine a loader plugin that enabled:

 import legacy:foo;

 Which would evaluate the module in a script context.

 Yehuda Katz
 (ph) 718.877.1325


 ___
 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

Re: import script -- .esm

[Matthew Robb]

On Wed, Sep 10, 2014 at 12:20 PM, Anne van Kesteren ann...@annevk.nl
wrote:


 (I think text/javascript is just fine btw. text/* works great for HTML
 and CSS too. In any event, for the purposes of the browser JavaScript
 does not really have a MIME type. We parse anything we get...)

 ​The problem is that there are now two distinctly different types of
javascript file, some should be parsed as script and some should be parsed
as module. Assuming everything is script that is not explicitly module
would work but I don't see how you can accurately guess without some sort
of hint that you need to parse as module.​
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script -- .esm

[Matthew Robb]

As soon as the language decided it would have a differentiation for modules
vs scripts then it seems only natural that it should also specify at least
some generic means of entry into one mode or another. Then it's up to
browsers or who ever to determine what external signifiers would trigger
module instead of script. Or the language parsing logic could say that in
the presence of module syntax it will always be treated as module. I don't
know if that's feasible or not *shrug*


- Matthew Robb

On Wed, Sep 10, 2014 at 12:21 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Sep 10, 2014, at 8:44 AM, Matthew Robb wrote:

 Personally I have felt this way for a long time as well. I think `.esm` is
 somewhat confusing since most js developers don't really think about it as
 EcmaScript. I would think you could just as easily do `.jsm` but this also
 suggests that files of this alternate should be served with a different
 mime type such as `text/javascript-module` or something along those lines.


 I also agree (and have argued) that an external discrimination of modules
 and scripts is going to be a practical necessity and that file extension is
 the most natural way to do so.  Consider a couple basic situations:

 1) linters need to know whether whether to apply script or module
 (including implicit strict) to the source files they process.

 2) a command line js engine needs to know which source files listed on the
 command line are intended to be processed as scripts which need to be
 loaded as modules.

 command line switches or other affordances could be used to make this
 discrimination.  But file extensions are the more traditional approach.

 But, such conventions seem to be outside the scope of ECMA-262.  .js isn't
 something that has appeared in any standard, as far as I know.

 Allen




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script -- .esm

[Matthew Robb]

Alternatively you could argue that some of the hooks in Loader shouldn't be
in the language spec because they should likely exist outside of something
that is hyper-specifically a module loader. So if the web has a resource
loader construct similar to ES6 Loader and it would handle resolving paths
and it would handle fetching etc then the ES6 Loader needs to be concerned
with much less.

If `.js` is not in any ES spec then why was there ever the idea of auto
appending it to modules? I feel like this whole region of concerns is a bit
mixed up right now.


- Matthew Robb

On Wed, Sep 10, 2014 at 12:39 PM, Axel Rauschmayer a...@rauschma.de wrote:

 Modules and scripts can not always be identified by inspection.  Consider:

 foo.js ---
 const answer = 42;
 ---

 The semantics of this are quite different depending upon whether foo.js is
 evaluated as a script or loaded as a module.


 Given that module files and script files have different semantics, I would
 definitely want different file endings for them – for both humans and
 machines. 1JS doesn’t apply here.

 Axel

 --
 Dr. Axel Rauschmayer
 a...@rauschma.de
 rauschma.de




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script -- .esm

[Matthew Robb]

There are numerous discussions about this throughout the last two years and
you can find record of them throughout es-discuss. Someone closer to the
topic can likely fill you in but I won't try to pull that information off
the top of my head.


- Matthew Robb

On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:



 On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:

 As soon as the language decided it would have a differentiation for
 modules vs scripts then it seems only natural that it should also specify
 at least some generic means of entry into one mode or another. Then it's up
 to browsers or who ever to determine what external signifiers would trigger
 module instead of script. Or the language parsing logic could say that in
 the presence of module syntax it will always be treated as module. I don't
 know if that's feasible or not *shrug*


 Modules and scripts can not always be identified by inspection.  Consider:

 foo.js ---
 const answer = 42;
 ---

 The semantics of this are quite different depending upon whether foo.js is
 evaluated as a script or loaded as a module.

 Allen



 But why?

 To be completely serious. Why do we have to make a difference?


 ___
 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

Re: import script -- .esm

[Matthew Robb]

Some info was discussed here: http://esdiscuss.org/notes/2014-01-28


- Matthew Robb

On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:



 On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:

 As soon as the language decided it would have a differentiation for
 modules vs scripts then it seems only natural that it should also specify
 at least some generic means of entry into one mode or another. Then it's up
 to browsers or who ever to determine what external signifiers would trigger
 module instead of script. Or the language parsing logic could say that in
 the presence of module syntax it will always be treated as module. I don't
 know if that's feasible or not *shrug*


 Modules and scripts can not always be identified by inspection.  Consider:

 foo.js ---
 const answer = 42;
 ---

 The semantics of this are quite different depending upon whether foo.js is
 evaluated as a script or loaded as a module.

 Allen



 But why?

 To be completely serious. Why do we have to make a difference?


 ___
 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

Re: import script -- .esm

[Matthew Robb]

Yeah heres a bit more in depth discussion on the topic:
http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-12


- Matthew Robb

On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:



 On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:

 As soon as the language decided it would have a differentiation for
 modules vs scripts then it seems only natural that it should also specify
 at least some generic means of entry into one mode or another. Then it's up
 to browsers or who ever to determine what external signifiers would trigger
 module instead of script. Or the language parsing logic could say that in
 the presence of module syntax it will always be treated as module. I don't
 know if that's feasible or not *shrug*


 Modules and scripts can not always be identified by inspection.  Consider:

 foo.js ---
 const answer = 42;
 ---

 The semantics of this are quite different depending upon whether foo.js is
 evaluated as a script or loaded as a module.

 Allen



 But why?

 To be completely serious. Why do we have to make a difference?


 ___
 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

Re: import script -- .esm

[Matthew Robb]

So my thought based on this comment:
http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-14

Why not deprecate sloppy-script mode explicitly and encourage the movement
to module-strict for all scripts moving forward. Once you do that then you
can make the decision to spec the legacy code path as separate from the
modern code path. Then implementors would already be adhering to the legacy
code path for existing stuff and a convention would need to be decided upon
(somewhere) for differentiating the from the new.

I would go so far as to suggest the file extension `.es` to denote this and
at some point a different mime-type probably. So files with .es extension
or that contain module syntax of any kind would be treated as modules and
anything not conforming to that would be treated like a sloppy script...
Including files imported from modules that don't meet either of those
requirements.


- Matthew Robb

On Wed, Sep 10, 2014 at 1:03 PM, Matthew Robb matthewwr...@gmail.com
wrote:

 Yeah heres a bit more in depth discussion on the topic:
 http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-12


 - Matthew Robb

 On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
 wrote:



 On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:

 As soon as the language decided it would have a differentiation for
 modules vs scripts then it seems only natural that it should also specify
 at least some generic means of entry into one mode or another. Then it's up
 to browsers or who ever to determine what external signifiers would trigger
 module instead of script. Or the language parsing logic could say that in
 the presence of module syntax it will always be treated as module. I don't
 know if that's feasible or not *shrug*


 Modules and scripts can not always be identified by inspection.  Consider:

 foo.js ---
 const answer = 42;
 ---

 The semantics of this are quite different depending upon whether foo.js
 is evaluated as a script or loaded as a module.

 Allen



 But why?

 To be completely serious. Why do we have to make a difference?


 ___
 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

Re: import script -- .esm

[Matthew Robb]

I don't see why they have to? Traceur should be used as a build time tool
that ultimately runs in legacy mode. Only REAL modern ES6 module
implementations would run in this other world. Basically .es files today
would be transpiled into .js files.


- Matthew Robb

On Wed, Sep 10, 2014 at 1:22 PM, Brendan Eich bren...@mozilla.org wrote:

 Boil the ocean schemes never work, especially not on the Web. Indeed
 Allen's use of dream to describe the hope that in the far future
 everything is module code is not unfair. Dreams do come true, but only
 incrementally where there's local advantage.

 Saw your followup to my Nope-topus post. You wrote Legacy and should be
 ignored as much as possible. Good luck with that, I don't see how it
 flies. Is everyone going to switch to Traceur quickly or even slowly?

 /be


 Matthew Robb wrote:

 Why not deprecate sloppy-script mode explicitly and encourage the
 movement to module-strict for all scripts moving forward. Once you do that
 then you can make the decision to spec the legacy code path as separate
 from the modern code path. Then implementors would already be adhering to
 the legacy code path for existing stuff and a convention would need to be
 decided upon (somewhere) for differentiating the from the new.

 I would go so far as to suggest the file extension `.es` to denote this
 and at some point a different mime-type probably. So files with .es
 extension or that contain module syntax of any kind would be treated as
 modules and anything not conforming to that would be treated like a sloppy
 script... Including files imported from modules that don't meet either of
 those requirements.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script -- .esm

[Matthew Robb]

I just think the idea of 1JS has already been compromised and really what
we have is a spec that supports two almost-entirely different sets of
expectations. The maintenance of keeping them of equal priority seems like
it will only get worse over time. The `use strict` pragma is already sort
of an opt-in to the new mode. To me the more graceful path forward is the
one where the world as people know it stays the same but then there is an
opt-in path for moving to the supersets of the future. Dong this once after
having considered many of the issues of the old model seems reasonable to
me specially with the amount of buy in people are doing on transpilers and
even buy in on other languages/runtimes such as dart.



- Matthew Robb

On Wed, Sep 10, 2014 at 1:33 PM, Brendan Eich bren...@mozilla.org wrote:

 Matthew Robb wrote:

 I don't see why they have to? Traceur should be used as a build time tool
 that ultimately runs in legacy mode. Only REAL modern ES6 module
 implementations would run in this other world. Basically .es files today
 would be transpiled into .js files.


 I doubt people will do any such thing. We can have more suffixes (I was
 against .js2 in particular -- that particularly confusing proposal was why
 I unleashed the Nope-topus), but if people can adapt their existing
 practices with AMD/Require/CommonJS modules and use just .js, I bet they
 will.

 Tools will have to read metadata, tea-leaves, and etheric winds to keep
 up. Same as ever.

 /be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss