Re: Power operator, why does -2**3 throws?

[Kevin Smith]

It's a committee-compromise grammar hack.

On 3:52AM, Thu, Oct 20, 2016 medikoo 
wrote:

> ES is already not free from such cases, e.g. `!'property' in object` will
> also not resolve as most will expect.
>
> I understand and agree that case is ambigous and is problematic. It just
> feels very controversial to me that it was decided that this case will be
> handled differently than others that share exactly same problem.
>
> For those who are not aware of all such quirks/inconsistences it leaves
> feeling that language is unpredictable in its behaviors.
>
> On 10/18/2016 01:05 AM, medikoo wrote:
> > There are many other cases when with no parens involved, people have
> > different expectations on the outcome.
> > If expression looks ambigous the actual result always depends on
> operators
> > precedence, it's how language worked for years, and I don't remember any
> > big
> > problems due to that.
> >
> >
> > Jordan Harband wrote
> >> It's quite simple (as has already been stated): some people expect `-x
> **
> >> y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`.
> >>
> >> The early SyntaxError ensures that nobody is confused - programmers will
> >> immediately add parens to disambiguate.
> >>
> >> Avoiding a potential footgun for the next 50 years, at the insignificant
> >> cost of adding two characters so that it parses seems like a very cheap
> >> price to pay.
> >>
> >> On Tue, Oct 18, 2016 at 12:20 AM, medikoo 
> >> medikoo+mozilla.org@
> >> 
> >> wrote:
> >>
> >>> I must say throwing here, instead of relying on math dictated operators
> >>> precedence looks really bad.
> >>> It's very surprising to those well experienced with the language, and
> >>> totally inconsistent with how operators worked so far (there is no
> >>> previous
> >>> case where one will throw for similar reason).
> >>>
> >>> Also argument that it's inconsistent with Math.pow(-2, 2), is total
> miss
> >>> in
> >>> my eyes.
> >>> I believe to most programmers `Math.pow(-2, 2)`, translates to
> >>> `(-2)**(2)`
> >>> and not to `-2**2`,
> >>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
> >>> c)**(2)` and not to `a ? b : c**2`
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context: http://mozilla.6506.n7.nabble.
> >>> com/Power-operator-why-does-2-3-throws-tp359609p359731.html
> >>> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> >>> Nabble.com.
> >>> ___
> >>> es-discuss mailing list
> >>>
> >> es-discuss@
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359733.html
> > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> > Nabble.com.
> > ___
> > es-discuss mailing list
> > es-discuss@
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
> --
> View this message in context:
> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359853.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.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: Support () => {}() syntax?

[Kevin Smith]

Ideally there will be an `async` version of do expressions, which evaluate
to a promise:

```
let promise = async do {
  await something();
};
```

(BTW, if we get such a thing, we might not really need
top-level-module-await...)

On Fri, Sep 30, 2016 at 2:39 AM Olivier Lalonde  wrote:

> Do "do expressions" support the "await" keyword?
>
> On Thu, Sep 29, 2016 at 3:59 PM, Rick Waldron 
> wrote:
>
>>
>>
>> On Thu, Sep 29, 2016 at 3:14 PM Michał Wadas 
>> wrote:
>>
>>> Similar proposal is already here, do expressions.
>>>
>>
>> Additionally...
>>
>>>
>>> On 30 Sep 2016 12:06 a.m., "Olivier Lalonde"  wrote:
>>>
 I occasionally write IIFE to avoid introducing `let` variables, e.g.:

 ```
 const thumb = ({ width, height }) => {
   const { w, h } = (() => {
 // if either width or height is set, don't set any default
 if (Number.isInteger(width) || Number.isInteger(height)) {
   return { w: width, h: height }
 }
 return { w: 400, h: 400 }
   })()
   // ...
 }
 ```

>>>
>> Why introduce the function and cognitive overhead?
>>
>> const thumb = ({ width, height }) => {
>>   const w = Number.isInteger(width) ? width : 400;
>>   const h = Number.isInteger(height) ? height : 400;
>>   // ...
>> }
>>
>>
>> Either way, `do` expressions are what you're looking for.
>>
>>
>> Rick
>>
>
> --
> - Oli
>
> Olivier Lalonde
> http://www.syskall.com <-- connect with me!
> ___
> 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: Endorse an unambiguous syntax for ES2015 modules

[Kevin Smith]

I suggest re-reading Domenic's two replies; they quite exhaust the topic, I
think.

On 12:31AM, Wed, Sep 7, 2016 martin heidegger 
wrote:

> > This is not correct. There is nothing backward-incompatible about
> adding a new top-level grammar goal. And the new grammar goal has even less
> impact on Node.js, which does not use the existing grammar goal that the
> spec gives them (Script).
>
> I might be overseeing something but
> https://github.com/bmeck/UnambiguousJavaScriptGrammar#example ← The
> examples given here are incompatibilities. (right?!) In browsers the "this"
> would be "window" instead of  "global". Any text editor, any tool that
> tries to work with a given .js file would need to decide which approach to
> use for processing (i.e. code-completion). With unspecified out-of-band
> metadata editors would have a hard time to guess the format as well.
> Browsers, Node.js and editors (have to) care about this non-specification.
>
> (Nothing indicates to me that using the word "hole in the spec" is an
> inappropriate representation of the situation ...)
>
> > Browsers have chosen to solve this with out-of-band metadata...
>
> This basically requires any other solution to play ball. If the TC39
> doesn't consider an unambiguous specification then I think it would be
> important to specify another set of out-of-band metadata recommendations in
> the interest of the JavaScript ecosystem. i.e. something like "Files SHOULD
> treat .js files having the former logic and .esm files as having the new
> logic. A mime-type `application/es-module` CAN also clearly indicate the
> content type and when used HAS to be treated with a higher priority than
> the file ending."
>
> This would be important for browser as well: They could judge whether a
> loaded file is intended to be an esm or not and show an error message.
>
> > ... will disagree with your assessment ...
>
> I am open to be enlightened. I consider the TC39 members to be reasonable,
> intelligent persons. A lack of agreement shows just to me that there is a
> lack of information to all parties, keeps them form being decisive about
> it.
>
> best regards
> Martin Heidegger
>
>
>
> On 7 September 2016 at 13:04, Domenic Denicola  wrote:
>
>> From: martin heidegger [mailto:martin.heideg...@gmail.com]
>>
>> > Thank you for taking the time to answer. For some reason it seems like
>> > I framed it to be a Node.js specific issue. In my understanding the
>> current ES2015 module specification is ambiguous regarding backwards
>> compatibility.
>> > Node.js or Browser that surely is an issue for the implementers?! This
>> > seems like a hole/bug/problem in the specification to me. (Please
>> correct me if I am wrong). And it also seems to me like this is a serious
>> issue.
>>
>> This is not correct. There is nothing backward-incompatible about adding
>> a new top-level grammar goal. And the new grammar goal has even less impact
>> on Node.js, which does not use the existing grammar goal that the spec
>> gives them (Script).
>>
>> It's true that there are source strings that match both the Script and
>> Module goals. But this is not a problem for backward-compatibility, and
>> calling it "ambiguous" is a stretch. (Is the string "Hello, world!" a
>> text/plain or text/html file? It's "ambiguous", I guess, but no known
>> software has problems with this "ambiguity".)
>>
>> So the specific proposal of "unambiguous module grammar" is very much a
>> Node.js specific issue. It's even worse than that: it's a Node.js specific
>> issue where the proposal is to turn that Node.js specific issue into a
>> restriction placed on all host environments, not just Node.js.
>>
>> > This problem can be solved in my understanding either by adding
>> out-of-band metadata (file extension, mime-type, ...) or within the file (
>> shebang like comments, "use strict" like spec etc.).
>>
>> Yes, exactly. Browsers have chosen to solve this with out-of-band
>> metadata (`import` only works on modules, not scripts, and 

Re: Reason for strange ExponentiationExpression & UpdateExpression productions?

[Kevin Smith]

It's pretty weird.

On Wed, Jul 20, 2016 at 3:55 PM Jordan Harband  wrote:

> `-x ** y` is absolutely a SyntaxError because of the disagreement between
> many programming languages which treat that as `(-x) ** y` and math itself
> which treats it as `-(x ** y)`.
>
> To resolve the debate about "what will users expect", this early syntax
> error ensures that programmers get the joy of being required to be explicit
> about their precedence, saving countless amounts of time and money spent on
> linting rules and style arguments.
>
> On Wed, Jul 20, 2016 at 12:48 PM, Bradford Smith <
> bradfordcsm...@google.com> wrote:
>
>> Can anyone explain the reasoning behind the strange "leapfrogging"
>> behavior of the ExponentiationExpression
>>  and
>> UpdateExpression  
>> productions
>> in the current spec?
>>
>> Simplified relevant productions in operator precedence order are:
>>
>> ExponentiationExpression :
>> UnaryExpression
>> UpdateExpression ** ExponentiationExpression
>>
>> UnaryExpression :
>> UpdateExpression
>> { delete | void | typeof | + | - | ~ | ! } UnaryExpression
>>
>> UpdateExpression:
>> { ++ | -- } UnaryExpression
>> LeftHandSideExpression { ++ | -- }
>>
>> Things that seem weird about this are:
>> 1. '-x ** y' is a syntax error, because UnaryExpression isn't allowed
>> before **
>> You must write it as '(-x) ** y'
>> I would expect the production right hand side to be
>> UnaryExpression ** ExponentiationExpression
>> That avoids this strange syntax error and is consistent with the
>> pattern followed by productions for lower-precedence operators.
>>
>> 2. Having UnaryExpression in the right hand side of UpdateExpression
>> confuses precedence by going 'backward' to a lower-precedence non-terminal,
>> and the only production of UnaryExpression that generates a valid
>> argument for '++'/'--' is UnaryExpression => UpdateExpression =>
>> LeftHandSideExpression anyway.
>>
>> I've just finished implementing these rules in the closure-compiler,
>> where I had to implement logic to deal with this strange behavior. Is it at
>> all possible that these are simply typos in the spec?
>>
>> Thanks,
>> Bradford
>>
>> ___
>> 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: A plan to help TC39 become more open up to community contributions and participations

[Kevin Smith]

Thanks for pointing out some issues with the current state of things.
While, in general, having more people directly participate in the committee
is probably a good thing, I don't think that will fix the problem.  I think
you'll find yourself running into the same troubles that the current
members face.  Specifically, there is more work to be done than there is
time to do it.  There are more things to reach consensus on than there is
time to discuss.  Also, there is also the risk of perpetuating an unhealthy
"us-vs-them" mentality which seems to underly this plan and this post.

Instead (or perhaps simultaneously while you explore this plan) why don't
we try to address the community involvement problem?

The big problem, I think, is that community members are directed to
es-discuss and yet es-discuss has been largely been abandoned by TC39
committee members.  Why has es-discuss been abandoned?  There are a couple
of reasons I think:

1. Github (and their "issues" feature) has turned out to be a much better
platform for working out design details on particular proposals.  Community
members have successfully and productively participated in the design
process in this way.
2. The signal-to-noise ratio here is *really* bad these days.  Let's be
honest: most of the strawman proposals that are brought here are pretty
terrible.  It takes time to review and comment on even the worst ones, and
that's time that I (for one) would rather spend doing other things, like
working on observables, or cancel tokens, or private state, or async
generators, or drinking eine bier.

The other problem that I've heard mentioned is that certain high-profile
proposals (like that function-pipe one) aren't getting any traction.

First, there are *very* few proposals that fit into that category.  Claude
Pache's https://github.com/claudepache/es-optional-chaining is great!  In
general though, if a proposal isn't getting picked up it's probably because
either it has significant issues that committee members don't like, or the
time for it just isn't right.  Time is a limiting factor and we have many
proposals working through the process already.

I'll spend some time thinking about how we can improve the es-discuss
involvement problem.  Thanks again for bringing attention to it!


On Thu, May 26, 2016 at 8:06 AM G. Kay Lee <
balancetraveller+es-disc...@gmail.com> wrote:

> (This is a continuation of [a previous discussion](
> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues
> ))
>
> So, to summarize, while rules and platforms currently in place do allow
> for community contributions, they are hardly friendly ones. A few issues:
>
> * The mailing list is a really awkward platform for community participants
> to collaborate, especially when debates and discussions can span months,
> even years; threads, reasonings, and important conclusions tend to become
> buried over time, resulting in a never-ending reincarnation of dead ideas
> and, more importantly, lose of precious lores and insights.
>
> * Self-contradictory rules about the processing of community proposals in
> official documents, because these rules were [authored by a few different
> individuals without a definitive source](
> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues#content-17
> ).
>
> * The most widely circulated version of these rules demands community
> proposals to find "champions", ie. member representatives willing to serve
> as lobbyists; the real story, however, is that member representatives are
> very busy and, when they do have time, they will almost always lobby for
> proposals that their organizations or themselves are interested in. No
> blaming here because this is just the way human society works, which brings
> the conclusion that this requirement is simply antihuman.
>
> In the previous discussion, Allen mentioned that a lot of efforts have
> already been put in place to make TC39 as open as possible under the bylaws
> and rules of Ecma International, for which I am sure every non-member
> participant of the standardization process is really appreciated. But I
> think there is still room to do better.
>
> For that reason I intend to form a nonprofit organization and apply for
> Ecma membership to help further opening up the standardization process of
> ECMAScript to interested participants who currently do not enjoy the
> privilege of becoming member representatives.
>
> I've been in contact with Secretary General Istvan and apparently this is
> doable as long as the General Assembly vote in favor of my application, so
> I think it's a good thing to raise this plan here and see if anyone has any
> good feedbacks or concerns, so we can iron out these issues during the
> early stage - or put an early end to it if there are some good reasons. A
> legally registered nonprofit with an official "tax exemption" status is the
> acceptance criteria for Ecma NFP members, but also requires me to go
> 

Re: Import wildcards

[Kevin Smith]

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

Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

>
> I will note that JavaScript does already require n-token lookahead worst
> case to disambiguate arrow functions from sequence expressions.
>
The syntax is actually specified in terms of cover grammars, not arbitrary
lookahead.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Class and Property Initialization

[Kevin Smith]

>
> That said, it has one problem -- base classes.  You can't seal them
> because the constructor in the extended class would fail (I tried it)
> and so the base classes would always have to remain  unsealed which
> means you either (1) understand that or (2) always use an extended class
> if you care for level of code safety.


One idea that I've been playing around with:  instead of thinking about
class property definitions in terms of normal object properties, what if
they were sugar for a private field with a getter and setter?  For instance,

class A {
  x = 100;
  constructor() { Object.seal(this) }
}

is sugar for:

class A {
  #x = 100;
  get x() { return this.#x }
  set x(value) { this.#x = value }
}

If we did it like this, then it should work even with subclasses.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Async iteration

[Kevin Smith]

>
> Is there a summary of the motivation for "for-await" and "async iteration"
> in general?
>

There's a short section at:
https://github.com/tc39/proposal-async-iteration#overview-and-motivation


> Has there any discussion in not supporting "var" in "for-await"
> initializers?
>

Symmetry with for-of is definitely an important consideration.  Is there a
particular reason why you think "var" should be disallowed?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.prototype.forIn

[Kevin Smith]

1. How is a user supposed to intuit the difference between Object.keys and
Object.keysIn?  For a non-expert, it sounds like the same thing.
2. With "keys", "entries", etc., we lead the user down the "safe"
object-as-dict path.  Does adding these methods undo some of that leading?
What are the compelling use-cases for proto-chain-as-dict?

On Tue, Mar 8, 2016 at 3:23 PM Leo Balter  wrote:

> I have a proposal I'm finally bringing to es-discuss.
>
> https://github.com/leobalter/object-keysin-valuesin-entries-in
> (rationale, examples and steps included)
>
> I've already talked to some TC39 members about it and I believe it fits
> right on this topic.
>
> On Mon, Mar 7, 2016 at 5:48 PM, Bergi  wrote:
>
>> Langdon wrote:
>>
>> Something that simply wraps this all-to-common code:
>>>
>>> var key;
>>>
>>> for (key in obj) {
>>>if (obj.hasOwnProperty(key) === true) {
>>>  ...
>>>}
>>> }
>>>
>>
>> Imo the problem is not that there is no wrapper method for this pattern,
>> but that this code is all too common. It should rarely be needed, and is
>> mostly wrong anyway.
>>
>> The cases to consider are
>>
>> * You use `obj` as a dictionary. If you want to safeguard against
>> inherited properties, you use `obj = Object.create(null)`. Those objects
>> don't even have a `.hasOwnProperty` method.
>> And with ES6, a `Map` is a better solution anyway.
>>
>> * You are enumerating array keys. To safeguard against inherited
>> properties from `Array.prototype`, you should not use `hasOwnProperty` but
>> rather use the proper loop type that iterates indices instead.
>>
>> * You are processing JSON. `JSON.parse`'d objects inherit only from
>> `Object.prototype` which does not have enumerable properties anyway.
>>
>> * You are processing (JSON/dictionary) objects and fear that someone
>> added enumerable properties to `Object.prototype`. Well, that's their
>> fault, not your loop's one. If the environment is broken, your code is as
>> well; there's nothing you can - and need - to do against.
>>
>> * You are processing arbitrary objects with unknown prototype chains. To
>> skip inherited properties in a `for in` loop, the only safe approach is to
>> use `if (Object.prototype.hasOwnProperty.call(obj, key))` or avoid the
>> drama altogether via `Object.keys`/`Object.getOwnProperty…`.
>>
>> The last case is the only one where you'd really need `hasOwnProperty`.
>> The proliferation of `if (obj.hasOwnProperty(key))` needs to be stopped,
>> it's cargo cult programming at best.
>>
>> Regards,
>>  Bergi
>>
>> ___
>> 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 Proxy "apply" trap limited to function only?

[Kevin Smith]

> I thought `typeof (class {}) === "function"` as well. And classes, to my
> knowledge aren't callable.
>
Oh they are, they just throw when you call them : )

https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist
Step
2
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring an object into a new object (like Underscore pick but ESier)

[Kevin Smith]

>
> I can create a new object with ALL of these properties using a spread
> operator:
> let newObj = {...obj, quux: 4}
>
Let's not do this.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Kevin Smith]

>
> I have no problem with that, but do wonder, why? What is the downside of
>> proposals being on the tc39 hub starting at an earlier stage, if the
>> authors are so inclined? The upside is fewer broken links.
>>
>
Because having the tc39 "brand" on things sends a signal to the broader
community about the future state of ecma262?

Also, github forwards URLs when the repo is transferred, so we're good
there.  Case in point:  https://github.com/zenparsing/async-iteration

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

Re: Weak Reference proposal

[Kevin Smith]

I suggest that this one be left on tc39 since it's already there and there
is a history of weakref proposals anyway.  But in general we should only
move proposals to tc39 at stage .

On 6:32PM, Tue, Feb 16, 2016 Mark S. Miller  wrote:

> On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg  > wrote:
>
>> I think this proposal is currently at Stage 0, right?
>
>
> Right. It is stage 0.
>
>
>> Do we typically
>> put Stage 0 proposals on the TC39 GitHub? My understanding was that
>> proposals typically get moved after Stage 2.
>>
>
> Typically yes. My assumption is that our desire here was one way -- we
> want to ensure it is on the (tc39) hub once it is at stage 2. I was
> assuming there was no issue in the opposite direction, i.e., that we do not
> actively want to ensure that it is or is not on the hub prior to stage 2.
> Perhaps I misunderstood. Is there anything about this in our process docs
> or prior discussions?
>
> Certainly, if for some reason we wish to ensure that earlier proposals are
> not on the hub, it would be easy to move off, and then back on later. This
> has a cost in broken links. What is the compensating benefit?
>
>
>
>>
>> Dan
>>
>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
>> wrote:
>> > I have posted a stage 1 proposal for weak references in ES7 for your
>> perusal
>> > and feedback.
>> >
>> > https://github.com/tc39/proposal-weakrefs.git
>> >
>> > Thanks to Mark Miller and the authors of earlier proposals for help
>> with the
>> > document and content!  Finally thanks to a few intrepid early reviewers
>> for
>> > their edits, comments, and feedback.
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> 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: Any reason why __proto__ is not a well known symbol?

[Kevin Smith]

>
> Is there a migration to make it a Symbol in ES7?  (ignorant question?)
>

Object.getPrototypeOf and Object.setPrototypeOf are the "no-dunder" ways to
do it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why are ES6 class methods not automatically bound to the instance?

[Kevin Smith]

>
> One of the wonderful features of many prototype methods is that they can
> be borrowed and .call-ed on other objects (imagine if you couldn't
> `Array.prototype.slice.call(arguments)`!). Auto binding would cripple this
> feature, and it seems like opting out would be harder than opting in.


In general, there is often a tension between making the language "better"
(for some subjective value system) and maintaining consistency.  I think
maintaining consistency was the right call in this case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are the default Symbol.species accessors intended to be configurable?

[Kevin Smith]

>
> Is this a correct reading of the spec? Is this a bug in the spec?
> https://github.com/tc39/test262/blob/master/test/built-ins/RegExp/Symbol.species/symbol-species.js
>  tests
> that the RegExp[Symbol.species] property is configurable. Additionally, it
> appears to break at least one major webpage if RegExp[Symbol.species] is
> not configurable.
>

Check out the last two paragraphs of
https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects,
 which specifies the default property attributes for the standard built-ins.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Try/catch conditional exceptions in light of generators

[Kevin Smith]

>
> It appears that there are no proposals on the way to deal with it and it
> is a very real problem. What would be the correct process to bring more
> attention to it?
>

A proposal posted here : )

A few things to address (off the top of my head):

- There was an old proposal for catch guards
 based
on refutable
pattern matching
.  Should
the catch syntax be based on pattern matching?  If not, why not?  If so,
then we'll need an updated proposal for pattern matching first.
- If, instead of pattern matching, catch guards are based around some kind
of runtime "typing" (using that word loosely), how does that work with
Realms and duplicated libraries?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: monadic extension to do-notation

[Kevin Smith]

Why not just use await within `async do`?

On 12:19PM, Sun, Feb 7, 2016 Rick Waldron  wrote:

> What does this do?
>
>
> let finalPromise = do {
> let a;
> a <- b;
> }
>
>
> Currently, that's an expression that means "a less than negated b"
>
> Rick
>
> On Sun, Feb 7, 2016 at 12:07 PM Raphael Mu 
> wrote:
>
>> The ES Promise is an instance of Monad, a property that implies a much
>> more concise and expressive syntax for using Promise, by exploiting its
>> monadic properties. I've seen a lot of people complain about Promises
>> having too clumsy a syntax, and likewise for async/await.
>>
>> We now have the do-notation proposal (
>> http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and
>> monadic assignment would fit well into the syntax.
>>
>> The extension would allow use of `<-` within a do-expression for binding
>> Promise values to variables, and the computation would behave most
>> similarly to the Either monad in Haskell (in the following code, if
>> promiseA or promiseB reject, the result of the entire expression would be a
>> rejected Promise).
>>
>> (monadic extension)
>> ```javascript
>> let finalPromise = do {
>> let a <- promiseA;
>> let b <- promiseB;
>> let c = f(a, b);
>> g(a, b, c)
>> }
>> ```
>>
>> (desugared to async/await)
>> ```javascript
>> let finalPromise = (async () => {
>> let a = await promiseA;
>> let b = await promiseB;
>> let c = f(a, b);
>> return g(a, b, c);
>> })();
>> ```
>>
>> (desugared to ES6)
>> ```javascript
>> let finalPromise = promiseA.then(a =>
>> promiseB.then(b => {
>> let c = f(a, b);
>> return g(a, b, c);
>> })
>> );
>> ```
>>
>> The do-notation would apply Promise.resolve to the last expression (like
>> async and Promise#then), effectively returning another Promise. The current
>> proposal doesn't specify this behavior, but there are two ways about this
>> collision:
>>
>> 1. use an explicit version of do-notation, e.g. `async do { ... }` or
>> `do* { ... }`
>> 2. revise the do-notation proposal to always apply Promise.resolve to the
>> last expression
>>
>> Both choices give us a new Promise literal for free: `do* { x }` (1) or
>> `do { x }` (2) would be functionally equivalent to `Promise.resolve(x)`.
>>
>> The idea was briefly mentioned several years ago, but didn't attract much
>> attention (
>> https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html).
>>
>> This is an earlier draft of this proposal:
>> https://github.com/edge/es-monadic
>> ___
>> 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: Optional Chaining (aka Existential Operator, Null Propagation)

[Kevin Smith]

>
> Yes: the `?.` operator does not change the meaning of the subsequent `.`
> operator. I like to think of it as: the effect is local (short-circuiting
> aside), you are not switching between "modes". It’s a feature.
>

Just curious:  what's the rationale for that behavior, as opposed to "deep"
short-circuiting?  It seems like if I have a long query, like:

a.b.c.d

I think I would typically want to test that the whole query is satisfiable
(not just a single term), so I'll need to write:

a?.b?.c?.d
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Kevin Smith]

>
> In case `myForm.querySelector('select[name=foo]')` is not null, then
> `myForm.querySelector('select[name=foo]').selectedOptions` is always an
> HTMLCollection and has always a `length` property. If it is not the case,
> then either I made a typo, or I am testing some ancient browser that
> doesn’t support yet the `selectedOptions` property. In both cases, I want
> an exception to be thrown rather than an error to be dropped: it's easier
> to debug.
>

Makes sense, thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Kevin Smith]

Thanks for putting this together.  At first glance, I think the semantics
look pretty good.  The syntax still seems problematic, though, from an
aesthetic point of view.

The `obj ?. prop` form looks natural and aligns well with how this feature
appears in other languages.  The other forms are less natural:

obj?.[expr]
func?.(...args)
new C?.(...args)

I'm not particularly convinced by any of the other syntactic variants we've
seen.

That aside, I have a question about the semantics.  What does this do:

({ x: 1 }).x?.y.z;

Does it throw a ReferenceError?

In general, when this feature is used in other languages, do you tend to
see the optional operator stacked up for the rest of the member expression?
E.g.

obj.a?.b?.c?.d

In order to avoid reference errors "in the middle"?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specifying the Existential Operator using Abrupt Completion

[Kevin Smith]

>
> Since nobody seems to have taken this, I will submit a formal proposal for
> stage 0 very soon (before two weeks).
>

Thanks Claude - looking forward to it!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> I think F#'s cancellation approach is also worth mentioning in the
> discussion of alternatives as it has implicit but token-based automatically
> propagating cancellation.
>

If you have any good links to reference materials on F#'s cancellation
architecture, feel free to include them for future reference.  I was unable
to find anything that clearly explained how implicit cancellation tokens
are discovered by child tasks, for instance.

I find implicit cancellation to be somewhat sketchy.  For async functions,
it would mean that any await expression could potentially throw a
CancelError:

async function f() {
  let a = await 1; // This could throw?  What?
}

And there are certainly going to be scenarios where you *don't* want to
cancel a subtask.  It seems to me that cancellation semantics are best left
to the async operation itself, rather than assuming "crash-and-burn".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

Thanks for posting this.  Great stuff!


> On a page that loads 100 images four at a time, you would want 4 cleanup
> actions registered, not 100.
>

And in order to keep it to 4 you need a way to unregister the action when
you complete the operation, which the promise API doesn't give you.  I see.

Conceptually, you could of course set some "complete" flag when you finish
the operation and then have the cleanup action early-exit if that flag is
set, but that would be unwieldy.  And it wouldn't stop the unbounded growth
of the promise's handler list.

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

Re: Promises as Cancelation Tokens

[Kevin Smith]

Thanks Ron!  Comments inline...

> ·   Once a callback has been registered for asynchronous notification
> of a cancellation signal, it can later be unregistered.
>
Yes, I see how this could be helpful.

> ·   Asynchronous notifications are queued and handled at a higher
> priority than Promise continuations.
>
> ·   The reason for cancellation can be explicitly supplied. If not
> supplied, the reason would be a generic “The operation was canceled” error.
>
What's the benefit of allowing a user-supplied error?  (I assume that by
convention the reason should be an error type.)  I don't see that feature
in .NET.

> Since “source.cancel()” is executed synchronously, one would expect that
> `p` would be rejected. If the notification were merely added to the same
> micro-task queue as Promise “then” tasks, `p` would be resolved first.
>
I agree that your example, as written, is counter-intuitive.  However, is
it still counter-intuitive if I rewrite it like this?

// Suppose I have "cancelToken" and "cancel"
let p = new Promise((resolve, reject) => {
  Promise.resolve(1).then(resolve);
  cancelToken.promise.then(reject);
  cancel();
});

Written like this, it seems to me that the ordering is as expected.  Are
there use cases that require a higher priority, beyond user expectation
based on the API?

In .NET, cancellation notifications are executed synchronously, however
> this conflicts with the intent to ensure an asynchronous API is
> consistently asynchronous.
>
Right.  The trouble I have with introducing an ad-hoc callback API for
cancel tokens centers mostly around the handling and propagation of
errors.  In .NET, exceptions which occur inside of callbacks are propagated
synchronously to the caller via an AggregateException error collection.
But if the callbacks are truly executed asynchronously, where do the errors
go?  Do they propagate out to the host, like HTML event handlers?  It would
be unfortunate if no mechanism was provided by ECMAScript itself to handle
such errors.

Since we already have a well-defined and well-understood way to propagate
errors using promises, I would prefer to have the async registration
capability modeled as a promise, if possible.  There is that "unregister"
issue, though...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> Since checking `promise.state` is synchronous, we may as well just
> write a synchronous Cancel class instead:
>

Right - see upthread.  You do need some kind of callback method, though,
like `whenCancelled(callback)`.


> class Cancel {
> constructor() { this.requested = false }
> request() { this.requested = true }
> throw() { throw new CancelError() }
> }
>

We need to separate the capability to "read" the cancellation request from
the ability to request the cancellation.  That's why in .NET you have
CancellationTokenSource and CancellationToken.  But for JS, we should
probably use the revealing constructor pattern instead (discussed upthread):

let token = new CancelToken(cancel => { ... });
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> We have pretty sound cancellation semantics in bluebird 3.
>

Cool, I'm aware that cancellable promises have been explored in depth.  I'd
prefer to keep this thread focused on cancellation tokens though, and avoid
comparisons.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> The best approach in cases like this is to avoid the word altogether.
> The fact that there's confusion at all means people will mess it up
> and get annoyed, even if there's a "winner" in overall usage.
>

Hmmm...  Maybe

class CancelToken {
  constructor(init);
  get cancelRequested() : bool;
  whenCancelRequested(callback) : void;
}

Or more/overly tersely:

class CancelToken {
  constructor(init);
  get requested() : bool;
  whenRequested(callback) : void;
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> I think using promises as tokens would be problematic. It would have
> several issues:
>

Agreed with all of those.

It's also important to keep in mind that promises can be subclassed so it's
> fine to add properties to them if used for a specific purpose like
> cancellation.
>

We could use a promise subclass as the cancellation token, but then tokens
(and their constructor) would inherit things that really don't make sense,
like "CancelToken.resolve" and "CancelToken.prototype.catch".

On the other hand, it doesn't really make sense to create a new callback
API (`whenCancelled`), when we already have the necessary callback
semantics with promises.  Perhaps we can expose a promise on the token
instead:

class CancelToken {
get requested() : bool;
get promise() : Promise;
throwIfRequested() : void;
}

// Registering a callback
token.promise.then(_=> doSomething());

// Doing other things with the promise
Promise.race(token.promise, someOtherPromise);
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Promises as Cancelation Tokens

[Kevin Smith]

I'm interested in exploring the idea of using an approach similar to .NET's
cancelation tokens in JS for async task cancelation.  Since the cancelation
"flag" is effectively an eventual value, it seems like promises are
well-suited to modeling the token.  Using a promise for a cancelation token
would have the added benefit that the eventual result of any arbitrary
async operation could be used as a cancelation token.

First, has this idea been fully explored somewhere already?  We've
discussed this idea on es-discuss in the past, but I don't remember any
in-depth analysis.

Second, it occurs to me that the current promise API isn't quite ideal for
cancelation tokens, since we don't have synchronous inspection
capabilities.  For example, suppose that we have this async function:

async function f(cancel) {
  let canceled = false;
  cancel.then(_=> canceled = true);
  await cheapOperation(cancel);
  if (canceled) throw new CanceledOperationError();
  await expensiveOperation(cancel);
}

Now, when the `canceled` flag is checked before `expensiveOperation`, it
may be the case that the `cancel` promise has already been resolved (i.e.
[[PromiseState]] is "fulfilled"), but the `then` callback has not executed
yet.  In such a case `expensiveOperation` would be started, even though a
cancelation has been requested.

For this reason, it seems like some kind of synchronous inspection ability
is required in order to use promises as cancelation tokens.  With
synchronous inspection, the above function would be written something like:

async function f(cancel) {
  await cheapOperation(cancel);
  if (cancel.isFulfilled()) throw new CanceledOperationError();
  await expensiveOperation(cancel);
}

Without synchronous inspection, I think we'd need to introduce some new API
for cancelation tokens.

Thoughts?  (For the purposes of this discussion, let's avoid discussing the
relative merits of cancelable promises vs. cancelation tokens.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

> throw() { throw new CancelError() }
>

This should be `throwIfRequested` I think, e.g.

throwIfRequested() {
  if (this._requested)
throw new CancelError();
  }
}


> What would be the recommended way of keeping the internal state
> private? With a WeakMap?
>

Spec-defined objects can have "internal slots" (essentially private
fields), which can be simulated with WeakMaps.  Although a polyfill would
most likely just use underscored names.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> I am also unsure when .whenCanceled is necessary
>

Maybe in the case where you have a promise-returning function and you want
to reject the returned promise upon cancellation.

function delayWithCancel(ms, cancelToken) {
  return new Promise((resolve, reject) => {
setTimeout(resolve, ms);
cancelToken.whenCancelled(reject);
  });
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

And what's the deal, is it canceled or cancelled?  : )


On Mon, Jan 4, 2016 at 11:30 AM Kevin Smith <zenpars...@gmail.com> wrote:

> Is there a reason to use a Promise as the cancellation token, rather than
>> have something that is synchronously inspectable?
>>
>
> The only real downside of coming up with a new interface is that we have
> to standardize it.  : )  It's a core protocol.
>
> I agree that using a promise directly would feel awkward without a helper
> library.  You'd probably also want a method that would throw an error if
> the cancel token was activated (as in .NET
> https://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken.throwifcancellationrequested(v=vs.110).aspx
> ):
>
> cancelToken.throwIfCanceled();
>
> Instead of the more verbose:
>
> if (cancelToken.canceled)
>   throw new OperationCancelledError();
>
> I also like the revealing constructor pattern that Domenic mentioned.
> It's almost good enough, as-is, for converting from a promise to a
> cancelation token:
>
> new CancellationToken(cancel => somePromise.then(cancel));
>
> Nice!
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises as Cancelation Tokens

[Kevin Smith]

>
> Is there a reason to use a Promise as the cancellation token, rather than
> have something that is synchronously inspectable?
>

The only real downside of coming up with a new interface is that we have to
standardize it.  : )  It's a core protocol.

I agree that using a promise directly would feel awkward without a helper
library.  You'd probably also want a method that would throw an error if
the cancel token was activated (as in .NET
https://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken.throwifcancellationrequested(v=vs.110).aspx
):

cancelToken.throwIfCanceled();

Instead of the more verbose:

if (cancelToken.canceled)
  throw new OperationCancelledError();

I also like the revealing constructor pattern that Domenic mentioned.  It's
almost good enough, as-is, for converting from a promise to a cancelation
token:

new CancellationToken(cancel => somePromise.then(cancel));

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

Re: Re: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

Sidebar:  thanks to Isiah Meadows, the FBS proposal now also supports
constructor wrapping via the `::new` syntax:

let factory = SomeClass::new;



On Mon, Dec 14, 2015 at 9:00 AM Marius Gundersen 
wrote:

> Do we really need to add support for await in a pipeline syntax sugar when
> there already is a piping support in `.then()`? If you need to await
> something in that chain, then just use `.then()`.
>
> ```js
> let result = await fs.readFile('index.txt')
>   .then(aSingleParamFunction)
>   .then(anotherSingleParamFunction)
>   .then(x => multiParamFunction(x, 10));
> ```
>
> I really don't see much gain in adding this syntax when there is already a
> FBS proposal that covers most of the cases. The pipe operator only supports
> single param functions. With multiple params you either need to use
> fat-arrow (while FBS handles multiple params) or you need a special
> function that is curryable. So now we either need functions that is
> curryable (for |>) or a function that relies on the `this` value (for FBS),
> so libraries will probably need to be specially written for whichever
> proposal is added to the spec. It looks to me like FBS adds a lot more
> value than |> does.
>
>
> On Mon, Dec 14, 2015 at 2:05 PM, Bruno Jouhier  wrote:
>
>> `await` could be handled by with contextual lexing: handling `|> await`
>> as a single keyword.
>>
>> Another solution would be to collapse the two into a variant of the
>> pipeline operator: `|await>`, `|!>`, ...
>>
>> This could be an opportunity to revive the syntax sugar that was proposed
>> in http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
>>
>> ```js
>> // concurrency strawman
>> lines = fs.readFile!('./index.txt').split('\n');
>> // pipeline operator
>> lines = './index.txt' |!> fs.readFile |> str => str.split('\n')
>> ```
>>
>> ___
>> 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: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

I can confirm that function bind syntax is all rainbows and unicorns.

: p

On 9:49PM, Sat, Dec 12, 2015 Alican Çubukçuoğlu 
wrote:

> This is a terrible example. It looks a lot better with what's already
> available:
> ```javascript
> async function runTask () {
>   const file = await fs.readFile('./index.txt');
>
>   const all = await* file
> .split('\n')
> .map(fs.readFile);
>
>   console.log(all.join('\n'));
> }
> ```
>
> Also how do you explain this feature to a newbie? This operator is
> supposed to call the function at the RHS with the value at the LHS and now
> it also has a special case when there is `await` at the RHS. How more
> complicated will this proposal get for the sake of making it look useful?
>
> This proposal's aim should basically be turning this:
> ```javascript
> myFunc(myVar);
> ```
> into this:
> ```javascript
> myVar |> myFunc;
> ```
>
> If it is not useful by just doing that then it should simply be rejected.
>
> ---
>
> About the usefulness of this proposal, this one conflicts with the
> function bind syntax and assuming FBS is all rainbows and unicorns and
> everyone should use it, then this proposal makes no sense since the
> original example should be written like this (and it's already good enough):
> ```javascript
> function doubleSay () {
>   return this + ', ' + this;
> }
> function capitalize () {
>   return this[0].toUpperCase() + this.substring(1);
> }
> function exclaim () {
>   return this + '!';
> }
>
> const result = 'hello'
>   ::doubleSay()
>   ::capitalize()
>   ::exclaim(); // "Hello, hello!"
> ```
>
> It's also weird that how the RHS of PO become weird when the function
> takes extra parameters. You can see how the code becomes polluted:
> ```javascript
> // Have fbFunc) with 0 parameters
> citizen::fbsFunc();
>
> // Add a parameter to fbsFunc()
> citizen::fbsFunc(param);
>
> // Have opFunc() with 0 parameters
> citizen |> opFunc;
>
> // Add a parameter to opFunc()
> citizen |> _ => opFunc(_, param);
> ```
>
> So we would be lying if we said the PO syntax is `param |> func`.
>
> The reality is:
> ```javascript
> // FBS syntax:
> param1::fbsFunc(param2);
>
> // PO syntax:
> param1 |> _ => opFunc(_, param2);
> ```
>
> This is no good.
> ___
> 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: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

>
> ```js
> // Assume fs.readFile is an `async` function
> async function runTask () {
>   './index.txt'
> |> await fs.readFile
> |> file => file
>.split('\n')
>.map(fs.readFile)
> |> await Promise.all
> |> all => all.join("\n")
> |> console.log
> }
> ```
>

This doesn't work unless you special case the semantics of await
expressions.  With the current semantics, `await fs.readFile` will just
await `fs.readFile` not the result of applying it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

>
> - I don't like the requirement to use the keyword `this` to compose
> functions. JS already has many features to support the keyword `this`:
> prototypes, method invocations, function binding, arrow functions, and
> probably others. I prefer a feature that assists the other side of the
> spectrum.
>

Yep - a well documented critique.  It depends on your point of view, I
think.  If you view these things as "extension methods", then using `this`
makes more sense.

- The fact that there are new semantics to what looks like a normal
> function call (e.g. `->map(...)`) doesn't set well with me. You could argue
> that it's something to get used to. Even in that case, I would expect the
> first argument I give to `map` to stay the first argument.
>

This is a reasonable objection, I think.

With the pipeline operator, partial application is left to the developer.
> They can choose to use arrow functions, or to curry their functions. I
> think this is the best option since it keeps things simple (no new
> semantics), and remains readable – see the "Function with Multiple
> Arguments" section in the GitHub link
> https://github.com/mindeavor/ES7-pipeline-operator
>

I agree that your proposal wins points for simplicity (both semantic and
syntactic), but having to create an arrow function to pass more than one
argument feels a bit awkward and seems to defeat some of the readability
benefit.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

Hi Gilbert,

Have you seen https://github.com/zenparsing/es-function-bind/ ?  It's a
function bind-syntax proposal which covers some of the same use cases
(although by binding the `this` parameter instead of passing the first
arg).  We've also explored some alternatives more closely aligned with your
proposal.  Check out the discussion here for the latest state:
https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154237803
and
feel free to comment!

On Tue, Nov 10, 2015 at 11:54 AM Gilbert B Garza 
wrote:

> Hello, I'm a JavaScript programmer and instructor who loves functional
> programming and writing concise, readable code. I think in general
> JavaScript supports programming in a functional style quite well. However,
> there is one small missing piece that I miss from other FP languages: the
> simple-yet-useful pipeline operator.
>
> Similar to F#, Elixir, Elm, and other FP languages, the pipeline operator
> |> helps make multiple function invocations more readable. Basically,
> `sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the following
> functions:
>
> ```js
> function doubleSay (str) { return str + ", " + str; }
> function capitalize (str) { return str[0].toUpperCase() +
> str.substring(1); }
> function exclaim (str) { return str + '!'; }
> ```
>
> you could use the pipeline operator to expand your invocations for
> readability:
>
> ```js
> // old way:
> // var result = exclaim(capitalize(doubleSay("hello")));
>
> // new way:
> var result = "hello"
>   |> doubleSay
>   |> capitalize
>   |> exclaim;
>
> // or, if you like one-liners:
> var result = "hello" |> doubleSay |> capitalize |> exclaim
>
> result //=> "Hello, hello!"
> ```
>
> You can see a few more examples, including an advanced example with
> Promises, here: https://github.com/mindeavor/ES7-pipeline-operator
>
> I'm inclined to think this feature is small and straight-forward to
> implement. Other than the operator, there are no new semantics. The syntax
> transformation is simple, and all existing code would remain unaffected.
>
> Although small, this feature increases the expressiveness of JavaScript
> significantly by opening more API design possibilities. You can see this in
> the link I included above.
>
> Thanks for reading. Any thoughts or comments?
> ___
> 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: Generator getter method

[Kevin Smith]

The existing option is:

let rect = {
  get corners() { return this._corners(); },
  *_corners() { .. },
};

which doesn't seem so bad.  Also, a generator getter would introduce a bit
of divergence between getter and setter syntax.

On Tue, Nov 10, 2015 at 2:28 PM Mohsen Azimi  wrote:

> Can we allow generator getter methods?
>
> Here is an example use case:
>
> ```
> let rectangle = {
>   start: {x: 1, y: 5},
>   width: 2,
>   height: 3,
>
>   *getCorners() {
> let {x: startX, y: startY} = this.start;
> yield this.start;
> yield {x: startX + this.width, y: startY};
> yield {x: startX + this.width, y: startY + this.height};
> yield {x: startX, y: startY + this.height}
>   }
> }
>
> for (let corner of rectangle.getCorners()) {
>   console.log(corner);
> }
> ```
>
> I'm proposing to allow  `get coreners* () { ...` (a generator getter
> method) so the for..of loop can be written like this:
>
> ```
> for (let corner of rectangle.corners) {
>   console.log(corner);
> }
> ```
>
> Which seems cleaner
> ___
> 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: resolve()/reject() on Promise subclasses and @@species

[Kevin Smith]

>
> Should it be corrected before @@species is widely implemented? I think so.
>

I agree, if feasible.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default call constructor behavior

[Kevin Smith]

A downside of specifying a default like this is that adding a "call
constructor" (can we think of a better name for this?) to an existing class
would become a breaking change for users of that class.



On Mon, Oct 26, 2015 at 8:49 AM Isiah Meadows 
wrote:

> I was using F.p.partial as merely an example. There are others I could
> have used. The main problem related to 4 is `apply`ing a constructor
> without needing to bind it.
>
> I rarely have the use case for F.p.partial myself, unless I'm
> experimenting with point free style (which is admittedly not very idiomatic
> JS).
>
> On Mon, Oct 26, 2015, 06:22 Mark S. Miller  wrote:
>
>> Since this thread seems to be taking F.p.partial seriously, as a possible
>> future spec to take into account, I should clarify that I never saw an
>> argument for it I found compelling. If anyone active on the committee feels
>> otherwise or is thinking about championing it, please speak up. Otherwise,
>> I would not worry about this being in our future.
>>
>> If it should gain widespread use as a user-written library function, then
>> of course we should reconsider. Its advocates should try that approach
>> first and see how far it gets. After all, that's where F.p.bind came from.
>>
>>
>>
>>
>> On Mon, Oct 26, 2015 at 4:35 AM, Claude Pache 
>> wrote:
>>
>>>
>>> > Le 26 oct. 2015 à 03:59, Isiah Meadows  a
>>> écrit :
>>> >
>>> > According to the current call constructor proposal, the behavior for
>>> > classes without call constructors is to unconditionally throw.
>>> > Shouldn't this be changed to automatically calling the constructor? I
>>> > see this as better for several reasons:
>>> >
>>> > 1. It's consistent with most of the builtins, including all of the new
>>> > ES6 types.
>>>
>>> No, new builtins are specced to protest when you forget `new` (except
>>> for `Symbol` where it is the other way round).
>>>
>>> > 2. It's easier to integrate into several libraries. I've run into a
>>> > ton of issues with trying to add support for ES6 classes in a specific
>>> > library written for ES5 for this reason. I can use `C.apply(null,
>>> > args)` instead of `new (Function.apply(C.bind,
>>> > [null].concat(args)))()`.
>>>
>>> You should use `Reflect.construct()` or a shim for it, here.
>>>
>>> Also, note that the expectation that `Foo(...args)` is equivalent to
>>> `new Foo(...args)` doesn’t stand for user-defined pre-ES6 constructors
>>> unless they include specific boilerplate. So, anyway, you or the library
>>> you’re using should not make such an assumption when working with
>>> constructors they don’t own. For constructors they own, the call
>>> constructor proposal will make easy to opt-in for that feature.
>>>
>>> > 3. It's easier to use in functional programming. (`titles.map(Book)`
>>> > instead of `titles.map(title => new Book(title))`)
>>>
>>> Fair. But your `Book` constructor should be explicitly documented that
>>> it does the same thing when called as when constructed, since that pattern
>>> won’t work with all classes. And if the documentation should be explicit,
>>> so should be the implementation.
>>>
>>> > 4. It's easier to partially apply. It would make the implementation of
>>> > the proposed Function.prototype.partial very easy, as well as simplify
>>> > and speed up Function.prototype.bind for classes, as assumptions can
>>> > be made.
>>>
>>> `Function.prototype.partial` might be simplified under the assumption
>>> that `Foo(...args)` is equivalent to `new Foo(...args)`, but you can’t make
>>> that assumption in the general case, so you have to implement it the
>>> "complicated" way anyway. The only potential advantage is that it may be
>>> easier for engines to detect when it is possible to do a specific
>>> optimisation.
>>>
>>> —Claude
>>>
>>> >
>>> > --
>>> > 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
>>>
>>
>>
>>
>> --
>> 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: Decorators for functions

[Kevin Smith]

>
> I would just say that it is odd in the extreme that a group of
> world-leading language designers would just throw in the towel when
> confronted with a pretty small roadbump, instead of figuring out ways to
> solve it.
>

Another drive-by...

The trick is introducing new features without exploding the number of rules
which must be remembered in order to use that feature.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Fix Left-Associative Compound Conditional Statements!!

[Kevin Smith]

>
> Actually, scratch that, its not even JUST a matter of convenience. A
> simple evaluation in your developer console will tell you that this
> currently evaluates inconveniently (I am avoiding the term "incorrectly"
> here because it is not theoretically incorrect if we consider these
> evaluations left associative):
>

Since this proposal would change the semantics of existing valid programs,
it would be a breaking change.  And breaking changes aren't really
"allowed" (breaking the web and all that).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Kevin Smith]

>
> We should have just made toplevel let/const/class create global
> properties, like var. This is how it was proposed originally


Can you provide (or link to) a more specific proposal?

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

Re: Global lexical tier

[Kevin Smith]

>
> I don't see how strict/sloppy mode effects the behavior of top-level
> lexical declarations. Does the behavior depend on strict mode?
>

No, V8 just currently disallows the use of let/const/class outside of
strict mode.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Kevin Smith]

 because the right-side-up way to say that is:

 e - a * c


Yeah, I was waiting for someone to point that out, after I hit send.  : )
 I should spend more time setting up a better examples...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Kevin Smith]

 x ** y ** z is easier to read/write than x.pow(y.pow(z))

That might be cherry picking.  Trying to make up something a little more
complex:

a**b * -c**d + e

Math.pow(a, b) * -Math.pow(c, d) + e

a.pow(b) * -c.pow(d) + e

I don't have strong feelings on this issue, but the third option looks
pretty good to me.  If we had some form of pipelining syntax (yet to be
proposed), then we could have:

let { pow } = Math;
a-pow(b) * -c-pow(d) + e;

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

Re: Computed Property Name Shorthand Proposal

[Kevin Smith]

 I'd expect the following to work, given that the prop expression evaluates
 to 'bar', and bar is in context.

 var foo = 'bar'
 var bar = 'ponyfoo'
 var baz = { [foo] }
 console.log(baz)
 // - { bar: 'ponyfoo' }


Hmmm...  I'm not sure I would expect any such thing.  It seems like you're
proposing some kind of dynamic eval-ish variable binding lookup, which is
probably going to be a no-go.

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

Re: JSDoc3-style operator to access property of prototype(s)

[Kevin Smith]

 class Child extends Parent {
   method () {
 // TODO: do something more than Parent would
 return Parent#method.call(this);


This would be written return super.method();


 var args = Array#slice.call(arguments, 0);


var args = Array.from(arguments);

(or rest params)

Have all use cases for this idea already been squashed by ES2015?


Yes, for the common use cases.

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

Re: Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

 What about `a!?.b` since semantically the symbol `!` has a meaning of
 non-nullable in JSDoc[1].


! in this context typically means non-optional, or throw if the value is
nill.  See Swift for example.

Or just `a!.b`?


Same thing.

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

Re: Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

 In TypeScript `?` means optional. But throw if the value is nil is the
 same same as non-nullable?


In Swift, the postfix ! operator unwraps an optional value, throwing if
nil.

See
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Better place for discussion?

[Kevin Smith]

 Is there a better place than this list to ask design questions that cover
 current best practice, upcoming features, and possible improvements to the
 language?


We don't generally cover best-practice or programming advice here, but
obviously anything to do with extending the language or filling gaps is
welcome.  Proposals should be well-thought out, but questions can be short
and quick.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal for a null coalescing operator

[Kevin Smith]

I just noticed that null/undefined was addressed in the OP, my apologies.

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

Re: Proposal for a null coalescing operator

[Kevin Smith]

A link to a wikipedia article is not *actually* a proposal : )

As Michael points out, you need to at least provide some consideration for
null vs. undefined.  I would also like to see some thought given to how
such an operator might interact with a null propagation operator, discussed
here:

https://esdiscuss.org/topic/existential-operator-null-propagation-operator

(Link appears to be temporarily not working...)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.substitute

[Kevin Smith]

 let yearSentence = ({year:2015}=`This year is ${year}`)();


Enclosing the template string inside of a function is the way to go.  Let's
call this one done.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Named Arrow Functions

[Kevin Smith]

 x.map(factorial(x) = do {
 if (x = 1) {
 1;
 } else {
 x * factorial(x - 1)
 }
 });


This has been discussed over the years but there has been very little
interest in making the grammar more complicated.  After all, you can always
just assign the arrow function to a locally-scoped variable.  And as Daniel
pointed out, this suggestion actually conflicts with async arrow functions.

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

Re: Please help with writing spec for async JSON APIs

[Kevin Smith]

Hi Moshen,

The semantics of your proposal are straightforward, so I don't think you
need to provide spec text at this point.  Instead, what would be helpful is
a quantitative analysis showing why these additional methods are needed.
Is there any way you can demonstrate the benefit with numbers?


On Fri, Jul 31, 2015 at 11:04 PM Mohsen Azimi m...@azimi.me wrote:

 Hi,

 I stumbled on lack of async APIs for JSON parsing and stringifying in
 JavaScript a couple of weeks ago. I tried to hack
 http://azimi.me/2015/07/30/non-blocking-async-json-parse.html around it
 by abusing the W3C Fetch API but that's just a hack.

 Domenic suggested https://twitter.com/domenic/status/626958415181393920
 that we should write the proposal spec for native non-blocking JSON
 processing. I don't know what the API should look like but I made some
 assumptions and wrote the initial spec (if I can call it spec!) and
 published it in GitHub https://github.com/mohsen1/async-json.

 I need to learn the spec lingo and rewrite the spec in proper and standard
 language. I need help and resources to learn the language of the spec.

 Would you please review the proposal so far (including the outstanding PR)?

 Thanks,
 Mohsen
 ___
 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: await on synchronous functions

[Kevin Smith]

 I know the spec for this isn't finalized, but what is the current
 direction for the behaviour when await is used on a function that is not
 marked async and doesn't return a Promise? Should it run immediately or
 wait for the next turn of the event loop?


More generally, the question is: what should await do for non-promises?

await 1;

Should it force a job to be queued?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: for statement with index and value

[Kevin Smith]

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.

On Mon, Jul 13, 2015 at 10:13 PM Tingan Ho tinga...@gmail.com wrote:

 Just following a discussion we had on TypeScript
 https://github.com/Microsoft/TypeScript/issues/3835

 In most times, I just need the value in an array, so I use a for..of loop.
 But then, I find out that I need the index too, then I need to rewrite my
 whole for loop expression. Happens all the time for me.

 I have to ask why there doesn't exist a `for statement` where I can get
 the index and value of an array directly? Or for that matter property and
 value of an object?

 `.forEach` is not ideal since you can't break, break to outer loop and
 continue cleanly. Even though you can achieve this with other array
 methods, I don't think they are as productive as a for-statement.

 What I'm suggesting is augmenting the current syntax for `for..of` loops.
 And support an overloading pattern so that we don't need to rewrite the
 whole for loop expression to just to get the index when we already getting
 the value.

 ```
 // overloads
 for (let value, index of values) { ... }
 for (let value of values) { ... }
 ```

 PS. Sorry if this has already discussed. Couldn't find any on Google and
 the esdiscuss.org page doesn't have any search capabilities.
 ___
 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: Instance bound class methods

[Kevin Smith]

 I am curious if https://github.com/zenparsing/es-function-bind would be
 related, since it would allow bound function calls to be made by using
 `obj::fn` while `obj.fn` would result in the unbound first class function.


Well, for that syntax proposal, it would be `::obj.fn`.

But see https://github.com/zenparsing/es-function-bind/issues/17 for some
interesting semantic issues around the object identity of such an extracted
method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Will any new features be tied to constructors?

[Kevin Smith]

 The essence of Dmitry's design is to disallow custom allocation, while
 allowing custom initialization. This allows you to optionally decouple the
 two stages when necessary (upgrades, cloning, etc.) while also getting the
 goodness where author code doing `new MyElement(...)` calls both built-in
 allocation and custom initialization immediately.


If we go with a private state design where the internal slots are not
dynamic, but fixed at birth (which is where we'd like to go), then a
becomes-like solution for custom elements wouldn't be compatible with
it.  It would mean that custom elements wouldn't be able to have usable
private slots.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Will any new features be tied to constructors?

[Kevin Smith]

The fact that you're dynamically changing the prototype as a part of this
solution is a strong indicator that this usage of subclassing is somewhat
questionable.  I suspect that you'll find other gotachas with this approach.

I understand that the DOM is dealing with some design constraints that are
less than ideal, but the only right ways to do this that I can think of
at the moment are:

- Swap out the element when the custom class is registered, as Allen
suggested.
- Use composition instead of subclassing to define custom behavior.



On Wed, Jul 1, 2015 at 10:56 AM Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Jun 30, 2015, at 8:31 PM, Domenic Denicola wrote:

  From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
 
  no, not in the way that I believe you intend
 
  Can you explain why? Is the design you and Kevin have been working on
 based on lexical restrictions?

 No sure what you specifically mean.  It requires that private slots be
 declared as part of a class definitions so that the metadata need to
 allocate them is available to the class constructor.


 
  It isn't that  subclass specific private state initialization must be
 performed in the constructors. In the design that Kevin and I have been
 working on,  the total number of private state slots (and some meta data
 for each one) must be knowable and fixed when an object is allocated   (in
 other words, private slots cannot be added to an object after it is
 initially allocated).
 
  This seems like it then compares poorly with weak maps for private
 state. It makes sense as a strong mode restriction, but not as a default
 one...

 It is the conventional model of private state that is used by most
 languages. It has lots of very desirable characteristics.  And, it's hard
 enough to insert one private state model into ES.  We aren't going to end
 up with more than one, at the language level.

 
  Anyway, the design for upgradable custom elements is based around the
 idea that subclasses would never need to customize the allocator, thus
 allowing the UA to do their magical allocation of C++ HTMLElement stuff. If
 private state requires customizing the allocator, I am not sure that custom
 elements would be able to take advantage of it anyway... I suppose it
 depends on the details of the proposal.
 

 This is model is, to a first approximation the C++ model and the also the
 model the ES currently uses for built-ins so I don't expect that UA
 allocators will have significant difficulties supporting it.

 Allen


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

Re: Will any new features be tied to constructors?

[Kevin Smith]

 I actually do have a related question, though.  In the private state
 proposals we're talking about, how would it be observable whether the
 private slots the class defines are in fact allocated as part of the
 object's allocation or separately?


Not sure I understand the question.  If the internal shape is fixed from
birth (allocation-time), there is no way to allocate private slots
separately.

Are you suggesting that the DOM could define some magic way to dynamically
allocate private slots and supposedly hide that fact from the user?

Only if you consider object identity and === as meaningless : )

let el = document.createElement(foo-bar);
let Custom = class extends HTMLElement {
private @x;
initElement() { this.@x = 1; }
getX() { return this.@x; }
};
try {
Custom.prototype.getX.call(el); // throws a TypeError: no @x
} catch (x) {}
document.registerElement(foo-bar, Custom);
Custom.prototype.getX.call(el); // No type error, returns 1
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Will any new features be tied to constructors?

[Kevin Smith]

 Ah, I see.  So what's observable is not whether things are a contiguous
 chunk of memory or whatnot but rather whether the slots exist.  And a
 proposed invariant is that the slots, once observed to exist or not
 cannot change that state.  Is my understanding correct now?


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

Re: revive let blocks

[Kevin Smith]

 Yes, I'm planning to prepare a proper spec for the September meeting. I'm
 also hoping we get a prototype impl in V8 some time later this year,
 although I'd rather not promise anything.


Cool - looking forward to it!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Incompatibility between generators and arrays in the Iterator protocol

[Kevin Smith]

If you use yield instead of return in your generator function you'll get
the desired results.  When using a generator function to implement
iteration, you'll generally want to avoid returning a final value, since
for-of ignores the return value.

The return value does have an important role to play in coroutine-style use
cases.

On 2:20PM, Tue, Jun 30, 2015 Tim Jansen m...@tjansen.de wrote:

 Hi,

 I am working on a collections library that supports the Iterable/Iterator
 protocol, but I ran into a stumbling block: the iterator protocol seems to
 work differently for arrays and generator functions. Array iterators set
 'done' to true *after* the last element, but function generators set 'done'
 to true *on* the last element.

 Is this incompatibility intentional, or or just an implementation issue in
 the browsers (tested on FF38 and Chrome 43)? I wasn't able to find any
 information on this. The ES6 draft from April '15 doesn't define when
 exactly 'done' is set.


 Code example:

 var a = ['a', 'b'];

 var itA = a[Symbol.iterator];

 itA.next();   // {value: 'a', done: false}

 itA.next();   // {value: 'b', done: false} !!

 itA.next();   // {value: undefined, done: true}


 function* b() {

   yield 'a';

   return 'b';

 }

 var itB = a[Symbol.iterator];

 itB.next();   // {value: 'a', done: false}

 itB.next();   // {value: 'b', done: true} !!!

 itB.next();   // {value: undefined, done: true}

 The difference is in the second invocation of next(), which returns true
 for generator functions. That protocol makes it impossible for me to
 support both generator functions and array iterators with the same
 implementation - at least if I want to support 'undefined' as a valid value
 in collections. I wouldn't be able to differentiate between an empty list
 ([]) and a list containing undefined ([undefined]).


 Thanks,

 Tim



  ___
 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: Will any new features be tied to constructors?

[Kevin Smith]

 The design is basically that the browser first creates a normal
 element, and at a later point changes the prototype and invokes the
 callback.


Changes the prototype dynamically?  We're generally moving away from such
shenanigans.

That would indeed interact poorly with some of the designs for private
state that we've been entertaining.  In such a scheme private state slots
are allocated when the object is created.  But in your use case you
wouldn't know what slots to allocate until after you've created the
object.  And then it's too late.

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

Re: revive let blocks

[Kevin Smith]

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


I think Andreas was interested at some point?

I've long been interested in the possibility of a do async as well. : )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: primitive boxing in instanceof due to Symbol.hasInstance

[Kevin Smith]

 https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instanceofoperator
 calls GetMethod on C without checking if it is an Object, this means `1
 instanceof Foo` could be affected by mutating
 `Number.prototype[Symbol.hasInstance]`.


I assume you mean without checking if O is an object


 I am assuming this is unintended?


IIUC the point of @@hasInstance is to allow the programmer to define
completely arbitrary semantics for instanceof when applied to C, even
if C is a built-in.  Do you see a problem with this behavior?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Language design

[Kevin Smith]

https://i.imgflip.com/mtot6.jpg

On Fri, Jun 12, 2015 at 6:55 PM KOLANICH kola...@mail.ru wrote:

 Hello all. I have opened the page
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla
 and was horrified. What happened with JS? Why do we need all this methods?
 Why a lot of functionality is now doubled, and a lot of new badly designed
 API and language features was introduced? I understand the word
 compatibility, but I think that no compatibility worth enough to be
 preserved sacrificing the language design making it self-contradictary.
 For example, Object.is compares identity. Operator === also compares
 identity but in a bit differrent way. Why not just make == check equality
 only between compatible types, === check identity (that the object is the
 same) and throw out Object.is. Operator [] casts its argument to string ...
 but not when used with Symbol (why not just allow the key to be any object
 and match using ===). New iterator API relyes on Symbol.iterator. Why do we
 need it? Why not just use strings and prototypes? fromCodePoint doubles
 fromCharCode, but differs a bit. Why didn't you repurpose fromCharCode,
 just allowing it to take a string arguments describing codepages?
 Iterability and enumerability are distinct, but iterability is just
 enumerability with numeric key (yeah, I know that it is possible to create
 endless or random iterator, but in fact this means that you just don't need
 to use the key provided). Why there is iterability, but not enumerability
 with properties of iterability and enumerability united? Why we need
 enumerability to make it work with for ... in and iterability to make it
 work with for ...  of? Why can't we use methods definitions to define
 methods as a function declaration? Why JS is so badly designed?
 ___
 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

[Kevin Smith]

 I'm not entirely sure if it's appropriate, but I just published a library
 called Trine[1] that takes advantage and displays the power of the proposed
 function bind syntax. Consider this my upvote for the proposal. :)


It's definitely appropriate, as long as it's clear to users that the `::`
syntax is experimental, non-standard and subject to change.  This is
actually the kind of usage feedback we were hoping to get : )

Has there been any discussion of anyone championing this proposal for
 ES2016? I would very much like to see it land, especially given that I've
 already been using it extensively in production via Babel. :P


Not sure you should use it in production, just yet...

I'm the champion for this proposal, and I plan on pursuing it.  I'm not
sure that it will fit into the ES2016 timeline though, given the time
remaining and other priorities (like async/await).  To be honest, I'm not
overly worried about which train it leaves on.

Since you brought it up...

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.

In other words, these forms would no longer be valid under the proposal
(although they could be re-introduced in another proposal):

let bf1 = ::obj.foo.bar;
let bf2 = obj::foo;

But this would still be OK:

obj::foo(bar);

Given your experience with the operator and your use cases, would you still
be in favor of such a minimal proposal?

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

Re: ES6 Proxy Function Call Trap

[Kevin Smith]

 So why not do that for ES6 proxies as well by adding an `invoke` trap.


Tom's response a couple of messages back summed it up fairly well.

To paraphrase, introducing invoke is a reasonable thing to propose
(evidenced by the fact that it was part of the spec draft at one point).
However, invoke in JS not a fundamental operation.  It's always been a
get followed by a call.  And since Proxies are all about allowing the
user to define arbitrary behavior for the fundamental object model
operations, it makes more sense to not have an invoke trap.

Could a userland library make writing these kinds of proxies more ergonomic?
___
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

[Kevin Smith]

Derp - email fail!  : )

You could always use parenthesis:


::(whatever).foo

But in any case:


 Right - I think there are going to be two points of contention regarding
 the prefix form:

 1. Is a unary prefix operator appropriate, given the somewhat magic
 dereference+bind behavior?
 2. Does the fact that `::obj.meth !== ::obj.meth` amount to a footgun?

 The infix form faces some different challenges:

 1. Is it okay to encourage the floating method style (a la Jussi's
 library)?
 2. Aren't we sacrificing polymorphism and is that a bad thing?


The question isn't really about whether infix and prefix are both good
things, the question is about whether it's best to fight both of those
battles at the same time.

Anyway, still thinking about it and I really appreciate everyone's input!
___
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

[Kevin Smith]

 A more interesting issue in my view is whether a prefix (`::obj.meth`) is
 the best syntax. An infix alternative like `obj-meth` might be interesting
 if the left term is itself a complex expression.


You could always use parenthesis:


Right - I think there are going to be two points of contention regarding
the prefix form:

1. Is a unary prefix operator appropriate, given the somewhat magic
dereference+bind behavior?
2. Does the fact that `::obj.meth !== ::obj.meth` amount to a footgun?

The infix form faces some different challenges:

1. Is it okay to encourage the floating method style (a la Jussi's
library)?
2. Aren't we sacrificing polymorphism and is that a bad thing?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

[Kevin Smith]

 Syntax for putting properties on the prototype was long-ago rejected
 because of footgun potential.


Correction:  *data* properties.  : )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

[Kevin Smith]

 Anyway, I'm curious to know why do you think getters and setters are OK
 and properties are not. I don't see any technical difference, specially
 considering get/set for lazy property computation/assignment through the
 prototype getter anyway.


Syntax for putting properties on the prototype was long-ago rejected
because of footgun potential.  Users will naturally tend to think of them
as per-instance, instead of shared, which leads to bugs.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

[Kevin Smith]

 Also static properties are on __proto__, so it seems a bit strange that
 instance properties would not also be on .prototype. Somewhat of a
 consistency issue I suppose.


Methods declared as static in ES6 are defined on the constructor itself.
Apparently, static data properties in TS are defined on the constructor
as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

[Kevin Smith]

 how about introducing a well known concept in JS as `own` ?

 ```js
 class Person {
   static name String: A person name
   own name String: anonymous
   own items Array: []


Let's take a step back and ask:  what's the motivation for having these
property declarations and initializers outside of the constructor?  As Mark
pointed out, it's a syntactic feature that is strictly less expressive than
the current solution of putting property assignments in the constructor
body.

Instance property initializer syntax is really geared toward type systems,
where you are expressing type constraints (either structural or nominal) on
objects created by the given constructor.

I'm wary of adding syntax whose primary motivation is to express type
constraints, when we haven't even defined (or proposed) what typing in JS
means.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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

[Kevin Smith]

Hi Logan - that's correct.

On Tue, Jun 2, 2015 at 11:08 PM Logan Smyth loganfsm...@gmail.com wrote:

 To clarify things, since I don't think it's been made abundantly clear,
 the example that Sebastian gave would work in a standard ES6 environment,
 correct? It is only if the callback were executed synchronously that the
 exception would be thrown since the `this` binding has not yet been
 initialized?
 Transpilers however have elected to prevent this to err on the side of
 ensuring that invalid ES6 allowed through because adding runtime checking
 for the `this` binding would be difficult?



 On Tue, Jun 2, 2015 at 7:37 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


 ___
 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: let function

[Kevin Smith]

 function-in-block does not have the same semantics as the proposed let
 function. It hoists, thus has no TDZ, and appears to preclude a reasonable
 decorator syntax behaviour,


But that would not fix the decorator/function problem.  Specifically, we
would not want to have a situation where let functions are decorable but
function declarations are not.


 and it has no provisions for const binding, i.e. const function.


A const function syntax was proposed during ES6 development and might
still be an option.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let function

[Kevin Smith]

Why not use a function declaration instead?

On Thu, May 14, 2015 at 2:37 PM Alexander Jones a...@weej.com wrote:

 Propose adding support for

 let function foo() {};

 which would have the equivalence of:

 let foo = function foo() {};

 The idea is to support the normal scoping of let, but without forcing you
 to repeat yourself when naming the function, whilst still having the
 function's name property be set.

 This would trivially extend to const and var. Also, possibly class.

 Thanks

 ___
 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: let function

[Kevin Smith]

 Good points. All the more reason to throw out declarations as statements
 in favour of let/const/var, which we all have to understand well
 anyway, for other types of variable.


Declarations aren't going anywhere, and there is zero interest in
deprecating them.  You might want to spend a bit more time learning the
spec or lurking before making proposals.

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

Re: function.next meta-property proposal

[Kevin Smith]

Alexander, ES6 generators accept any arbitrary values for the first
invocation of next.  That's not going to change.

On Thu, May 14, 2015 at 3:49 PM Alexander Jones a...@weej.com wrote:

 In Python, sending a value other than `None` into the first invocation of
 `send` raises an error. That seems like a reasonable behaviour to me,
 without introducing too much weirdness.

 TypeError: can't send non-None value to a just-started generator

 On Thursday, May 14, 2015, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:

 At the March TC39 meeting we agreed that the `function.next` metapropty
 should be made into a standalone stage 1 proposal.

 That proposal is now available at:
 https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md


 Allen

 ___
 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: Subclassing ES6 objects with ES5 syntax.

[Kevin Smith]

 const goodPromises = new WeakSet();
 class DefensivePromise {
   constructor(x) {
 super(x);
 if (new.target === DefensivePromise) {
   Object.freeze(this);
   goodPromises.add(this);
 }
   }
   static resolve(x) {
 if (goodPromises.has(x)) {
   return x;  // should be equiv to super.resolve(x);
 }
 return new DefensivePromise(r = {r(x)});
   }
 }


Basically you can't rely on new.target to mean what you think it means, in
the face of Reflect.construct.

Maybe this?

constructor(x) {
super(x);
// At this point you know that this is a Promise, but you don't
// know if the prototype is set correctly, so:
if (Object.getPrototypeOf(this) === DefensivePromise.prototype)
gooPromises.add(Object.freeze(this));
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing ES6 objects with ES5 syntax.

[Kevin Smith]

 So, ES6 Promises reflect a specific set of design decisions, including a
 specific definition of same type that appears to exist solely for use by
 Promise.resolve.  All that design guarantees is that the object has an
 certain specific internal slot whose value is tested in a specific way by
 Promise.resolve.  It doesn't guarantee that the object is a well-promise or
 that it has any specific other characteristics that are expected of Foo
 objects. It's hard to extrapolate from that  specific design to the
 underlying intent of the designer.


I don't see any rational intent for the current design other than:

Only return x if x was **constructed** by C.

The current semantic is:

Only return x if x was constructed by C, or any code with a reference to C
arbitrarily chose that it should appear to have been constructed by C.

Allowing an object to pass a nominal type test for a constructor, where the
object was not initialized by that constructor seems bad.

What is the use case for third argument to Reflect.construct?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Merge map values

[Kevin Smith]

Another option:

var map = new Map;
Array.from(mainn)
  .map(c = c.toLowerCase())
  .forEach(c = map.set(c, (map.get(c) | 0) + 1));

This kind of question is probably better left for StackOverflow, however.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing ES6 objects with ES5 syntax.

[Kevin Smith]

 Domenic, Kevin: the concern about Reflect.construct seems misplaced, but
 in any event, the issue C. Scott raises wants addressing on its own. WDYT?


Yeah, sorry for dwelling on Reflect.construct so much (it's in my mind for
other reasons).

So what would the ideal Promise.resolve semantics do?  I'm not sure, maybe
use SpeciesConstructor instead of [[PromiseConstructor]]?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing ES6 objects with ES5 syntax.

[Kevin Smith]

 x = Reflect.construct(Promise, x, C);

 is another fine way to fool someone who wrote C.resolve(x) and expected
 to get an instance of C back.


Thanks for pointing this out.  I believe the ability to use an arbitrary
newTarget parameter for Reflect.construct is breaking the intent of
Promise.resolve.  Using an arbitrary newTarget is also problematic for
the private fields proposal.

It seems to me that Reflect.construct has been given a capability that is
not otherwise expressible with ES6 syntax, and that gap is problematic.

Maybe I've missed some context though.  Mark, Allen, any thoughts?

Looking over the Reflect namespace, I also see that Reflect.get and
Reflect.set have been given powers not expressible with syntax:  the
receiver does not have to be a prototype parent of the target.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing ES6 objects with ES5 syntax.

[Kevin Smith]

 I think I'd rather see `Promise.resolve` changed to use `this.constructor`
 instead of `this.[[PromiseConstructor]]`, like every other Promise-related
 method.  Can someone who feels strongly otherwise give me the use case for
 `[[PromiseConstructor]]` existing?


I'll give it a shot.

Promise.resolve, executed on a constructor C, with argument x, should
only return x if x was created by C.[[Construct]].  Otherwise it should
create an instance of C which is resolved with x.

If we used x.constructor to determine the actual constructor, then
someone could just change the constructor property for x and fool someone
who wrote C.resolve(x) and expected to get an instance of C back.

It would be an unreliable, unsound conversion function.

Proper subclassing requires subclassing support from the engine.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

I think it's a good idea to attempt to express these ideas using existing
syntax and see what that might look like.

So, for a bit of fun, I wrote this:

https://gist.github.com/zenparsing/9ff3036b6eb15fa436e4

Basically, there's a Maybe function which returns a proxy over a target,
and returns Maybes for calls and gets.  Then there's a Definitely function
that unwraps the Maybe (unwrapping Nothing to undefined of course).

let scriptParent =
Definitely(Maybe(window).document.scripts[0].parentNode);

If you wanted syntactic sugar for this kind of thing, you'd probably want
postfix operators to replace the Maybe and Definitely function calls.

Swift does something similar with ? and !:

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html

This is kind of a generic monad pattern though, so it would be cool if the
syntax could be applied to other monad-ish things.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: super.prop assignment can silently overwrite non-writable properties

[Kevin Smith]

 ```
 var y = {
  __proto__: x,
  set prop(v) {
  // ...
  super.prop = v;
  }
 };
 y.prop = 42;
 ```


 Assuming `x` here is the object where prop is bound to an accessor, can
 you clarify how this would lead to an infinite recursion?


Assume let x = {};  (i.e. no property definition for prop on x.)

y is the receiver, so if you fall back to calling the receiver's accessor
somewhere in 5.e, you get infinite recursion.

Falling back to the receiver's accessor would be a bug in this case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: super.prop assignment can silently overwrite non-writable properties

[Kevin Smith]

 ```
 var parent = {};
 var v = 1;
 var x = Object.create(parent, {
   prop: { get: function() { return v; }, set: function(n) { v = n; },
 configurable: true }
 });


 Reflect.set(parent, prop, 2, x); // under Allen's proposed changes, this
 will return false while I think it should just call the setter?


Another interpretation might be that since you've explicitly stated an
intention to bypass the receiver's setter, falling back to that setter
would be a bug.

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

Re: super.prop assignment can silently overwrite non-writable properties

[Kevin Smith]

 5.e If *existingDescriptor* is not *undefined*, then
i.   If IsAccessorDescriptor(*existingDescriptor*), return *false*.
ii.  If *existingDescriptor*.[[Writable]] is *false*, return
 *false*.
iii.  Let *valueDesc* be the PropertyDescriptor{[[Value]]: *V*}.
iv.  Return *Receiver*.[[DefineOwnProperty]](*P*, *valueDesc*).

 Lines 5.e.i and 5.e.ii are new additions.


Looks good to me.

Thanks, Jason, for bringing this up!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Kevin Smith]

 We have `self` in DOM land too, so you can consistently use `self`
 across Window and Workers.


Why didn't I know this!?  Cool : )

 and `global` in most common server side JS engines

 Sounds like they should add `self`.  ;)


That would make sense.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings flags

[Kevin Smith]

 Why not provide special formatting flags for `Template strings`?


Tagged template strings are your friend.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

 Plus, it can be used for normalizing null/undefined to undefined:

  var normalizedFoo = ?foo;

 Seems sort of nice that it is separated and there are no special
operations for ?., ?(, ?[.

I agree, that is nice.  But how does Nil get transformed into undefined?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

 If we can come to an agreement on the existential operator for member
 expressions, we would also be setting a precedent for other features
 of the same family. For example, existential call expressions: `fn?()`
 which would conditionally invoke `fn`.


In the meeting notes you linked to, Waldemar (WH) noted that some of these
variations may have grammar issues.

Although not strictly ambiguous with conditional expressions, `fn ? ()`
would require the use of YACG (yet another cover grammar).

Also, what about computed property names?  For example:  `obj ?
[Symbol.iterator]`.  I'm not sure that even YACG will help here.

(Thanks for compiling the list of previous threads BTW).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: this value inside anonymous generator

[Kevin Smith]

Generator arrows are a possibility, but we need to see how the use cases
develop in practice. For the specific use case in the OP, async arrows
would actually be a better fit.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss