Re: Microtask scheduling

[Kris Siegel]

This seems more like a platform-level feature versus something that needs
to be part of the ECMAScript standard. Also, keep in mind it's rarely a
good idea to explicitly call nextTick() in node as it executes the code
immediately after the current code is finished and before the next,
scheduled code (this can cause issues with processing I/O if you're doing
it too frequently).

In a browser you can sorta emulate similar behavior through IE's
setImmediate(), using postMessage() or even the requestAnimationFrame().
Granted none of those are exactly like nextTick() and I wouldn't mind
seeing something like setImmediate() become more of a standard but this
isn't for the ECMAScript group.

On Wed, Jun 21, 2017 at 2:10 PM, Isiah Meadows 
wrote:

> It's a relatively low-level operation, but in performance-sensitive
> async code and polyfills, there's still a strong need for raw
> microtask scheduling, at a much lower level than promises. In
> particular, there's two very frequently used modules providing a
> wrapper for this specific thing:
>
> 1. next-tick: A browser polyfill for Node's `process.nextTick`, with
> over 2M downloads last month and 88 direct dependents.
> 2. asap: A microtask scheduler that avoids blocking Node's I/O loop,
> with over 7M downloads last month and 88 direct dependents.
>
> In addition, several libraries like Bluebird have to implement their
> own wrappers to gain similar functionality without assuming another
> dependency.
>
> Any chance something like Node's `process.nextTick` could be added,
> maybe something like `Promise.schedule(func, thisArg, ...args)`?
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why Number(symbol) crashes?

[Kris Siegel]

Symbol is such an oddball; similar to this if you do Symbol() + "" it will
also throw an exception unlike all other built-ins. Granted I have no idea
what a string representation of Symbol *really* would be but no other built
in type behaves the way Symbol does.

I do think Number(Symbol()) should return NaN though. I'd like to know why
this didn't happen.



On Tue, Oct 11, 2016 at 2:07 AM, medikoo 
wrote:

> I was searching the archived but wasn't able to find the answer.
>
> What's the reasoning behind having Number(symbol) crash instead of
> returning
> NaN (as it's in case all other non-coercible values?). It feels not
> consistent.
>
> If someone can point me to some discussion that provided the reasoning I'd
> be grateful
>
>
>
> --
> View this message in context: http://mozilla.6506.n7.nabble.
> com/Why-Number-symbol-crashes-tp359554.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: JSON.stringify

[Kris Siegel]

ECMAScript, while highly used in web browsers, should really not care about
HTML constructs. That's where WHATWG and W3C come in. I suggest this type
of feature should come from one of those groups, not ECMA.

On Wed, Sep 28, 2016 at 11:54 AM, Alexander Jones  wrote:

> Hi Michał
>
> Embedding a JSON literal into HTML involves first encoding to JSON then
> encoding that into HTML. Two stages which must not be confused. The
> 'encoding into HTML' part is best done in XHTML with CDATA, and the
> encoding method is taken care of by whichever XML-generating library you're
> using. If you hint it to use CDATA for such a text node, or if for any
> other reason it chooses to use CDATA, rather than merely converting every
> `<` to ``, etc., then it will (or should) "escape" `]]>` as
> `>". Mike Samuel has
>> a very strong point here.
>>
>> And by saying "it's antipattern, don't do this" we will not make old
>> vulnerable code go away. And we have a very good way to stop people from
>> shooting their own feet - for free.
>>
>> On 28 Sep 2016 8:31 p.m., "Alexander Jones"  wrote:
>>
>> That's awful. As you say, it's an antipattern, no further effort should
>> be spent on this. JSON produced by JavaScript has far more general uses
>> than slapping directly into a script tag unencoded, so no-one else should
>> have to see this. Also, there are many other producers of JSON than
>> JavaScript.
>>
>> Instead, use XHTML and CDATA (which has a straightforward encoding
>> mechanism that doesn't ruin the parseability of the code or affect it in
>> any way) if you really want to pull stunts like this.
>>
>> Alex
>>
>>
>> On Wednesday, 28 September 2016, Michał Wadas 
>> wrote:
>>
>>> Idea: require implementations to stringify "" as
>>> "<\uscript>".
>>>
>>> Benefits: remove XSS vulnerability when injecting JSON as content of
>>> 

Re: Make things like Reflect an import instead of a global?

[Kris Siegel]

Are there any proposals regarding built-in module mechanisms or at least
someone to champion it during ECMA meetings? Similar to Joe's point if this
isn't a blocking issue then releasing item after item into the global scope
means they are stuck there forever (unless something like "use stricter";
or whatever other silliness is added to gate the changes). This seems to me
like it shouldn't be that hard to do if someone is championing / proposing.

On Tue, Aug 23, 2016 at 8:26 PM, /#!/JoePea  wrote:

> True, I understand we can't practically do it at the moment since native
> module systems aren't implemented yet. I guess I am simply expressing that
> it would be awesome and that I can't wait for that to happen sooner than
> later so that new awesome features/tools can be modules instead of globals.
>
> The part that gives me a tiny bit of despair is that if something is
> released as a global, then it will stay that way essentially forever, for
> backwards compatibility. That is the part that makes me feel a tiny bit bad
> inside considering that the amazing language for modules is already defined.
>
> */#!/*JoePea
>
> On Tue, Aug 16, 2016 at 9:49 PM, Jordan Harband  wrote:
>
>> We don't yet have a mechanism for built-in modules, and that's not going
>> to be an obstacle for continuing to improve the language.
>>
>> As soon as a viable mechanism and precedent exists for that, new things
>> very well might only be added via that mechanism, rather than solely by
>> adding new global things.
>>
>> On Tue, Aug 16, 2016 at 6:52 PM, /#!/JoePea  wrote:
>>
>>> Seems like when the ES6 Modules became official that it would be a good
>>> idea to *not* define more globals in the language, and instead spec things
>>> to be modules, f.e. something like:
>>>
>>> ```js
>>> import {apply} from 'Reflect'
>>> // insead of
>>> const {apply} = window.Reflect
>>> ```
>>>
>>> This would also be a pattern for programs that use the JS engine to
>>> follow:
>>>
>>> ```js
>>> import {define} from 'CustomElements' // in browsers
>>> // instead of
>>> const {define} = window.customElements
>>> ```
>>>
>>> Maybe a symbol would be needed for any modules that are native?
>>>
>>> ```js
>>> import {define} from '#CustomElements' // # means native module
>>> ```
>>>
>>> */#!/*JoePea
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[Kris Siegel]

I agree but at the same time those examples simply look like bad coding
practices to me and we can't completely hide from those. Since it's new
semantics we shouldn't have to worry about it breaking something existing
and it would be really easy to do a transpile back into ES5 or ES6 should
people want to use it ahead of time.

Just my 2 cents. You certainly have valid points. The only awkward thing,
in my opinion, is if we're using let and const we're going to have to allow
var as well (it would be odd that, in a single place, you can use let and
const but not var). Not sure how var should be really handled here;
probably allow it but make it a bad practice to use var in this type of
declaration. In my opinion anyway.

On Thu, Sep 15, 2016 at 11:15 AM, Andy Earnshaw 
wrote:

> The main barrier that I can see is that this requires new semantics.  At
> the moment, variable declarations don't have any kind of usable result.  If
> you consider
>
> let a = eval('let b = 1');
> console.log(a);
> //-> undefined
>
> This sounds like an easy thing to solve, but how about this:
>
> if (let a = foo(), b = bar()) {
> }
>
> Does the block execute if `a` and `b` are both truthy, or just `b`?  My
> gut instinct says "if bar() is truthy", but it still seems awkward.  Any
> option might be confusing depending on your level of experience.   What
> about this:
>
> if (let { a, b } = foo) {
> }
>
> Does the block execute if `a` and `b` are both truthy, just `b`, or if
> `foo` is truthy?  I'd lean towards `foo` in this case, but I think it looks
> pretty bad and I'd hate to see it in code.  It might make more sense to
> throw for destructuring or if there's more than one assignment.
>
> On Tue, 13 Sep 2016 at 01:32 Danielle McLean 
> wrote:
>
>> In current ECMAScript, it is legal to place a variable declaration inside
>> the
>> initialiser of a `for` loop, as well as to declare the variable used by a
>> `for...in` or `for...of` loop within the declaring expression:
>>
>> for (let i = 0; i < 5; ++i) console.log(i);
>> for (let item of collection) process(item);
>>
>> When this syntax is used with `let` or `const`, the resulting variable is
>> scoped to the loop and is not visible to the rest of the surrounding
>> block.
>>
>> I propose that this syntax be extended, making it legal to place a
>> variable
>> declaration within the condition of an `if` or `while` statement. Any
>> truthy
>> value will cause the `if` block to run or `while` loop to repeat, as
>> usual -
>> the advantage is that the particular truthy value is bound to a variable
>> and
>> can be used inside the conditional block. For example, here is the
>> situation
>> that prompted my writing this proposal:
>>
>> if (const oldValue = _.get(object, 'some.long.path')) {
>>   object.some.long.path = transform(oldValue);
>> }
>>
>> As with the existing behaviour of declarations inside `for`, variables
>> declared
>> using `let` or `const` would be scoped to the individual `if` or `while`
>> statement, rather than the containing block. In other words, the above
>> syntax
>> would be equivalent to the following currently-valid form I ended up
>> writing:
>>
>> {
>>   const oldValue = _.get(object, 'some.long.path');
>>   if (oldValue) object.some.long.path = transform(oldValue);
>> }
>>
>> Another use case which C aficianados might recognise:
>>
>> while (const c = getchar()) {
>> process(c);
>> }
>>
>> This syntax is already legal in C++, although not in C - in general this
>> support is known as "anaphoric if", as it allows the body of the
>> statement to
>> refer back to the condition value. It's especially helpful in languages
>> with
>> truthiness, which ECMAScript has, as it allows access to the *specific*
>> truthy
>> value without further finagling.
>>
>> Thoughts?
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[Kris Siegel]

I really like the idea of declaring a variable directly in the conditional
itself. Many other languages do it. It's certainly not a critical thing (it
makes 2 lines of code into 1) but I certainly would like it to happen.
Considering it only moves the declaration I'm not convinced it makes code
harder to read; in fact since you are explicitly saying it's part of the
conditional you're declaring it in I feel like that makes it more clear as
there is no longer a risk of someone re-using that variable outside of,
say, the while loop it's declared in (which is what can happen today).

I know we don't have voting but this sure has my vote. I'd love to see it
championed at an upcoming meeting.

On Thu, Sep 15, 2016 at 9:22 AM, Andy Earnshaw 
wrote:

> How so? Assignment is already possible in control structures.  I think
> this reads better:
>
> ```
> if (let a = foo) {
> ```
>
> Than:
>
> ```
> let a;
>
> //...
>
> if (a = foo) {
> ```
>
> Having the `let` or `const` inside the conditional part clarifies the
> intent. There's an argument for not doing assignment inside the conditional
> part, but it's subjective and people will write code that way regardless.
> I'd much rather see `let` or `const` next to code like that if it means
> mistakes are less likely to be made.
>
>
> On Thu, 15 Sep 2016, 15:17 Mark Volkmann, 
> wrote:
>
>> For what it's worth, I'm on the side of people that do not want to see
>> assignment statements in control structures. I don't think it is necessary
>> and it results in code that is harder to read.
>>
>> On Wed, Sep 14, 2016 at 8:51 PM, Alan Johnson  wrote:
>>
>>> What about `else if`?
>>>
>>> On Sep 14, 2016 9:28 PM, "Bergi"  wrote:
>>>
 Danielle McLean wrote:

 variables declared
> using `let` or `const` would be scoped to the individual `if` or
> `while`
> statement, rather than the containing block. In other words, the above
> syntax
> would be equivalent to the following currently-valid form I ended up
> writing:
>
> {
>   const oldValue = _.get(object, 'some.long.path');
>   if (oldValue) object.some.long.path = transform(oldValue);
> }
>

 What about `else` blocks, would the variables be available in them as
 well?

 - 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
>>>
>>>
>>
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>> ___
>> 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: Extended dot notation (pick notation) proposal

[Kris Siegel]

> I'm just saying those references still exist, and ignoring them will lead
you into more problems than this would solve.

Not suggesting anything of the sort only that your workaround adds
additional variables with possible object references and a more native
implementation could work around that. Nothing more.

> And this isn't C: unless you're using those references, JS engines will
clean them up automatically, anyways, because of their garbage collection.
My workaround produces 0 more required object references than what the
engine needs.

Hmm this is interesting. It's been a while since I last memory profiled a
web application but the last time if I kept any references to, say, DOM
elements in any variables even if I was no longer using them they would
still be eating up the memory causing memory leaks. Are you saying this is
no longer the case? You don't need to necessarily get rid of all references
to, say, a DOM element before the garbage collector will sweep it up?

I'm more curious than anything else; it appears my understanding here might
be wrong so I want to dig into it more.

> Oh, and I've already suggested another, more specific, `pick` syntax

Good read. Interesting. Honestly I'm more of a fan of introducing functions
if possible to handle much of this instead of new syntax though I don't
know if that is necessarily supported by others and that proposal goes a
bit before what I was originally thinking.

On Tue, Sep 6, 2016 at 8:54 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> I'll note that the type checking part will eventually get fixed in
> TypeScript, at least.
>
> https://github.com/Microsoft/TypeScript/issues/1295
>
> Oh, and I've already suggested another, more specific, `pick` syntax (that
> operation is only a shorthand for `x => x.property`) ,but it ultimately got
> rejected since no one could really agree to anything different other than
> the current state was workable, but not optimal. You may appreciate reading
> the entire conversation, as it's pretty informative and is related to this.
>
> Here's the specific comment proposing that idea: https://github.com/tc39/
> proposal-bind-operator/issues/24#issuecomment-141331472
>
> Here's the issue where most the related discussion took place:
> https://github.com/tc39/proposal-bind-operator/issues/26
>
> On Tue, Sep 6, 2016, 13:07 Bob Myers <r...@gol.com> wrote:
>
>> Here is a little decision tree of the issues.
>>
>> [image: Inline image 1]
>>
>> On Tue, Sep 6, 2016 at 6:49 PM, Isiah Meadows <isiahmead...@gmail.com>
>> wrote:
>>
>>> > Isiah's workaround works but has the unfortunate side affect of
>>> copying values / increasing reference counts to objects. I'd love to see a
>>> built in solution.
>>>
>>> You'd have to do that anyways, even if it's entirely internal. How do
>>> you think you would do it outside of copying the values?
>>>
>>> On Mon, Sep 5, 2016, 19:45 Kris Siegel <krissie...@gmail.com> wrote:
>>>
>>>> Hmm I gotta say I must have re-read that minimally extended dot
>>>> notation proposal a few times and I just find the syntax confusing. I do
>>>> like the idea of building a way of taking a portion of an object out of one
>>>> object and into another but I don't think we need to provide additional
>>>> syntax rules to handle this. Why couldn't this be an Object.pick() addition
>>>> where it works similar to the underscore implementation? It could even be
>>>> expanded to handle deep nesting (I'm actually adding this to my msngr.js
>>>> library in the next release as grabbing a subset of an object is crazy
>>>> useful and I need to do it far too frequently).
>>>>
>>>> Isiah's workaround works but has the unfortunate side affect of copying
>>>> values / increasing reference counts to objects. I'd love to see a built in
>>>> solution.
>>>>
>>>> On Mon, Sep 5, 2016 at 2:38 PM, Isiah Meadows <isiahmead...@gmail.com>
>>>> wrote:
>>>>
>>>>> TypeScript has a fair number of proposals aiming to address this
>>>>> (things like difference types, partial types, etc.), but in general, I 
>>>>> find
>>>>> it just as easy to do it this way (which is easily checked):
>>>>>
>>>>> ```js
>>>>> const {toDate, fromDate, location, flavor} = this.state;
>>>>> const goodKeys = {toDate, fromDate, location, flavor};
>>>>> ```
>>>>>
>>>>> On Fri, Sep 2, 2016, 16:08 Bob Myers <r...@gol.com> wrote:
>>>>>
>>>>>> Here

Re: Extended dot notation (pick notation) proposal

[Kris Siegel]

Hmm I gotta say I must have re-read that minimally extended dot notation
proposal a few times and I just find the syntax confusing. I do like the
idea of building a way of taking a portion of an object out of one object
and into another but I don't think we need to provide additional syntax
rules to handle this. Why couldn't this be an Object.pick() addition where
it works similar to the underscore implementation? It could even be
expanded to handle deep nesting (I'm actually adding this to my msngr.js
library in the next release as grabbing a subset of an object is crazy
useful and I need to do it far too frequently).

Isiah's workaround works but has the unfortunate side affect of copying
values / increasing reference counts to objects. I'd love to see a built in
solution.

On Mon, Sep 5, 2016 at 2:38 PM, Isiah Meadows 
wrote:

> TypeScript has a fair number of proposals aiming to address this (things
> like difference types, partial types, etc.), but in general, I find it just
> as easy to do it this way (which is easily checked):
>
> ```js
> const {toDate, fromDate, location, flavor} = this.state;
> const goodKeys = {toDate, fromDate, location, flavor};
> ```
>
> On Fri, Sep 2, 2016, 16:08 Bob Myers  wrote:
>
>> Here's another StackOverflow question
>> 
>> essentially asking for pick notation. This same question pops up regularly.
>> It's the real world talking to us telling us what they need. In this
>> particular case, the solution with extended dot notation would just be
>>
>> ```
>> var goodKeys = this.state.{toDate, fromDate, location, flavor};
>> ```
>>
>> Perhaps I have not posted the minimal version of my proposal for this
>> pick notation
>> ,
>> also known as extended dot notation.
>> This version sacrifices some features in favor of complete compatibility
>> with existing destructuring syntax following the dot.
>>
>> There is another good reason these days for thinking about something
>> about this: *the advent of typed dialects of JS*.
>> We already know that a simple lodash-type version of pick, such as
>>
>> ```
>> function pick(o, keys) {
>>   return Object.assign({}, ...keys.map(key => ({[key]: o[key]})));
>> }
>>
>> const o = {a:1, b: 2};
>> const o2 = pick(o, ['a']);
>> ```
>>
>> cannot handle renaming or defaults or deep picking, but in addition *it
>> cannot also not be typed properly*.
>> For instance, `lodash.d.ts` defines `pick` as:
>>
>> ```
>> pick(
>>   object: T,
>>   ...predicate: (StringRepresentable|StringRepresentable[])[]
>> ): TResult;
>> ```
>>
>> with no type safety whatsoever.
>>
>> In contrast, with pick notation
>>
>> ```
>> const o2 = o.{a};
>> ```
>>
>> `o2` can be precisely typed by the compiler as an object containing the
>> property `a`, or a type compatible or assignable to that type.
>>
>> --
>> Bob
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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 ES6 introduced classes yet `Symbol` not to be used with `new`?

[Kris Siegel]

Interesting.

Because, to be consistent with Number/String/Boolean you would expect `new
> Symbol()` to create a  Symbol wrapper object.


Currently Symbol is the only primitive that can't be converted to a string
through the use of the + operator, so why the consistency in one place and
the lack thereof in another? I understand there isn't really a meaningful
representation of Symbol() as a string but I didn't see any particular
reason in my cursory look at the past notes for it to throw an exception so
I've been curious.

But we anticipated that if `new Symbol` was allowed many devs (who lacked
> an understanding of the difference between primitive values and wrapper
> objects for primitive values) would code `new Symbol()` with the
> expectation that they were creating a Symbol value. This would be a silent
> bug so we disallowed `new Symbol()`.


Forgive me for the ignorance but what kind of bug would this introduce?
Since Symbol() is already an oddball compared to all other built-in objects
and primitives would it have been so bad to simply make `new Symbol()`
equate to `Symbol()`? I'm not sure you'll get developers to understand the
difference between primitives and wrapper objects (still haven't found one
yet who understands this in my inner-circle of JS devs that I know at
least).


On Sun, Aug 14, 2016 at 9:18 PM, Domenic Denicola  wrote:

> I believe, but am not sure, that we also decided we would follow that
> pattern for any future primitive types, since in general constructing
> wrapper objects is a bad idea. (I want to say that wrapper objects
> themselves are a bad idea, but I think the conclusion was more subtle than
> that... they are an important part of the semantics, it's just unfortunate
> that they're so easy to create.)
>
> If some enterprising person wants to dig through the meeting notes, there
> might be some hints there...
>
> > From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
> >
> > Because, to be consistent with Number/String/Boolean you would expect
> `new Symbol()` to create a  Symbol wrapper object.  But we anticipated that
> if `new Symbol` was allowed many devs (who lacked an understanding of the
> difference between primitive values and wrapper objects for primitive
> values) would code `new Symbol()` with the  expectation that they were
> creating a Symbol value. This would be a silent bug so we disallowed `new
> Symbol()`.
>
> ___
> 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: Ignoring arguments

[Kris Siegel]

>
> ignoring/skipping argument in functions declarations (indeed the
> invocations could be let apart)


I am of the opinion that this is not a problem that needs to be solved at
the language standardization level. The commas (or really any separator)
for "skipping" a parameter looks like a mistake and is unintuitive (it's
certainly not obvious to me what its intent is had I seen it without the
context of this thread).

This seems like a problem solved with better coding practices. I typically
make required parameters first and then any optional ones in a separate,
single parameter called options. Callbacks can be done with chaining /
promises / I fmake them required / etc. Skipping callbacks usually isn't a
good idea. We could talk all day about who's coding practice is better than
who's but ultimately this problem should be solved by developing / adopting
good coding practices.

(Honestly I'm not a fan of the skipping in arrays either but considering
it's an array I feel like it's at least a magnitude less confusing than
doing it with function parameters)

On Thu, Aug 11, 2016 at 4:00 AM, Cyril Auburtin 
wrote:

> > Confused by this thread.
>
> It's quite simple though, _ would be a useless allocated variable, you
> an't have more than 1, ...
>
> > What is the problem that this proposal is trying to solve?
>
> ignoring/skipping argument in functions declarations (indeed the
> invocations could be let apart)
>
> > `Math.min(x,,y)`
>
> yes this kind of thing would give NaN, that's why you can `Math.min(x, ,
> y)` write it with more spaces to avoid a typo mistake, indeed you could
> still have like `Math.min(x, /*y (no longer used)*/ , z)` would. Like
> said above, I realize the function invocations are sensible.
>
> So, it would be only for function declarations
>
> `div.addEventListener('click', () => { } )` says to skip all arguments,
> and you've your callback scope is free of any additional vars
>
> `arr.forEach( x => { } )` says to only consider first argument, others are
> skipped, and not in scope
>
> `Array.from({length: 19}, (, i) => i )` would be similar for the second
> argument, similarly to array destructuring. It's not just for saving one
> character, that's really not the matter, it's for standardizing this way,
> because some people use `_`, some don't, 
>
> 2016-08-10 16:27 GMT+02:00 Bob Myers :
>
>> Confused by this thread.
>>
>> > What if you could use a `.` as a wildcard?
>>
>> You can already use `_` or anything you want, as was already pointed out
>> in early iterations of this idea.
>>
>> > it would avoid binding a usable identifier.
>>
>> What is the problem with that?
>>
>> What is the problem that this proposal is trying to solve? Any chance we
>> could move on?
>>
>> Bob
>>
>>
>>
>> On Wed, Aug 10, 2016 at 7:48 PM, Alan Johnson  wrote:
>>
>>> What if you could use a `.` as a wildcard? I don’t think it would
>>> conflict with existing syntax, and it would avoid binding a usable
>>> identifier. It would be more obvious than nothing between the commas.
>>>
>>>
>>> On Aug 8, 2016, at 06:33, Cyril Auburtin 
>>> wrote:
>>>
>>> Just bumping this up
>>>
>>> Calling `foo(1)` where foo is defined with 3 arguments, lets the 2
>>> others undefined, this behavior is already a bit magic and similar to the
>>> behavior of an array, so I still think foo(a,,b,,,c) should be like
>>> foo(...[a,,b,,,c])
>>>
>>> Other example:
>>> ```
>>> var m=new Map([[1], [2,], [3,7]]) // Map {1 => undefined, 2 =>
>>> undefined, 3 => 7} // here commas fantasies are allowed in arrays
>>> m.set(3) // Map {1 => undefined, 2 => undefined, 3 => undefined} //
>>> setting implicitely value as undefined
>>> m.set(3, ) // not allowed, which should be m.set(...[3,])
>>> ```
>>>
>>> and again, it would help for callbacks too, `something( ( , , thirdArg)
>>> => {} )`
>>>
>>> I saw this https://jeffmo.github.io/es-trailing-function-commas/, it
>>> seems like a sub-case
>>>
>>> 2016-05-29 23:07 GMT+02:00 Renki Ivanko :
>>>
 One more similarity is that both function parameters and destructuring
 allow default values: (foo = 1) vs [foo = 1].



 On Sun, May 29, 2016 at 11:56 PM, Cyril Auburtin <
 cyril.aubur...@gmail.com> wrote:

> Since functions arguments is an array under the hood, they could 'more
> behave the same'
>
> Both function arguments and arrays accept spreading: *[1, 2,
> ...args] * and *fn(1, 2, ...args)*
>
> a function definition like *(,i) => {}*, would be the equivalent of *var
> [,i] = arguments*
>
> an invocation *fn(,,i)* would be the equivalent of *[,,i]*
>
> It's possible with *(...[,i]) => {}, (_,i)=>{} *like Renki said, but
> slightly less simply
>
> Are there possible issues with that 'extension' of function syntax?
>
>
> 2016-05-29 21:32 GMT+02:00 Renki Ivanko 

Re: Function constants for Identity and No-op

[Kris Siegel]

I agree with Mark here plus we have const now which is perfect for
something like this if you wanted to take DRY to an extreme.

Ultimately seeing a function declared is obvious, seeing a special key word
is not. I have been in software development close to 15 years now and when
I first saw this I had to look up to remind myself what identity and noop
referred to (used the concepts many times but frequently forget what
they're called).

Sometimes DRY can be taken too far. This is one of those times IMO.

On Aug 10, 2016 7:33 AM, "Mark S. Miller"  wrote:

>
>
> On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman  wrote:
>
>> I can understand the sentiment of wanting brevity and avoiding
>> unnecessary abstraction, but in some cases I think it comes at the cost of
>> readability or good practice. This is why variables exist at all: to store
>> commonly used values either for reuse or to cut down on unnecessary
>> allocation.
>>
>> Sure, I could write code to ensure my numbers did go over a certain limit
>> with `Math.min(userInput, 9007199254740991)`, but readability and
>> abstraction give me something without having to keep this knowledge
>> internally and create my own allocation, e.g. `Math.min(userInput,
>> Math.MAX_SAFE_INTEGER`.
>>
>
> My message is about tradeoffs -- weighing costs against benefits. The
> costs I raise are cognitive burden.
>
> `x => x` has lower cognitive burden than `Function.IDENTITY`
> `9007199254740991` has much higher cognitive burden than
> `Math.MAX_SAFE_INTEGER`
> `3.141592653589793` has much higher cognitive burden than `Math.PI`
> `3` has lower cognitive burden than `Math.THREE`
>
>
>
>
>>
>> Now obviously it would be trivial for me to declare these constants in
>> userland code like I already do, e.g. `const NOOP = () => {}`
>>
>
>
> If there was a reason to do that, then it might make sense to consolidate
> these. However, this definition looks to me like a userland
>
> `const THREE = Math.THREE;`
>
> Whether in userland or not, such an "abstraction" only subtracts value.
>
>
>
>
>> , but in projects where it's needed in several files, I'll have to put
>> that in a module or re-declare everywhere. This is not a huge inconvenience
>> but something that could easily allocated for in the language.
>>
>> > The semantics of the named forms can be guessed rather well from the
>> names, but one cannot be sure without looking up or remembering their
>> definitions.
>>
>> This is true of anything; you know what you know, and are unsure of what
>> you are unsure of. Those that understand what a no-ops and identity
>> functions are will not need to look it up, and those that do not will look
>> it up until they know it. Just like my personal enemies `Array#shift` and
>> `Array#unshift`, I have to look those up every single time, and just
>> because I can't remember which is which or their individual case doesn't
>> mean they don't have value or that I resort to other tricks to avoid their
>> usage. All that to say, I don't think lack of knowledge is a valid argument
>> for these constants' non-inclusion. :)
>>
>> > Only pay these costs when the potential benefits are real.
>>
>> I think my allusion to potential benefits is avoidance of re-declaration
>> (DRY) and allocation.
>>
>> Just my thoughts. :)
>>
>> Eli Perelman
>>
>>
>>
>> On Wed, Aug 10, 2016 at 9:08 AM Mark S. Miller 
>> wrote:
>>
>>> On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows 
>>> wrote:
>>>
 I'll note that it's longer than just typing them out manually (and
 close if they're aliased):

 ```js
 Function.IDENTITY
 IDENTITY
 x => x

 Function.NOOP
 NOOP
 () => {}
 ```

 Not sure if it adds anything.

>>>
>>> Even aside from brevity, `x => x` and `() => {}` are more readable than
>>> `Function.IDENTITY` and `Function.NOOP` for a very simple reason. The
>>> semantics of the shorter forms are obvious and clear, give knowledge only
>>> of the core language. The semantics of the named forms can be guessed
>>> rather well from the names, but one cannot be sure without looking up or
>>> remembering their definitions. As we all know, abstraction has tremendous
>>> potential benefits. But it also has these costs -- the need to learn the
>>> meaning of new definitions. Only pay these costs when the potential
>>> benefits are real.
>>>
>>> Also, other things being equal, a briefer form is easier to read. In
>>> this case, other things are not equal but both considerations point in the
>>> same direction.
>>>
>>>
 On Tue, Aug 9, 2016, 14:44 Eli Perelman  wrote:

> I'm not sure if something like this has been proposed before, but I
> often find myself declaring constants for the identity function and the
> no-op function. I think it would be useful to have constants available on
> Function containing these values. For example `Function.IDENTITY` 

Re: Operating with arbitrary timezones

[Kris Siegel]

>
>  Once you endow them with a timezone offset they cease to represent
> points in time, but rather more points in space, which adds complexity and
> liability to any code handling Date objects


I would disagree. Time isn't useful without a point in space (space and
time should be looked at as one thing, not two) and since the Date object
tracks it internally as UTC it has a *default* space.

It's unfortunate that the boat has sailed on Date, because it's actually a
> very inappropriate name for what it is. But what I think is really needed
> is another distinct class for Date+Time components.


Completely agree. Other than adding functions nothing can really change
with the existing Date object. However this could be a real start to a new
set of standard libraries for JavaScript that require the usage of import
(so like Python, C++, C#, etc ECMAScript could have a set of libraries that
can be included in the exact same fashion as including external libraries).

I'm not really sure about not having arithmetic on this hypothetical new
set of components (arithmetic is one of the most useful things about date
time libraries) but that's details to be explored later and I guess this is
getting off track from the original proposal here.

On Fri, Aug 5, 2016 at 1:01 PM, Alexander Jones  wrote:

> I would object to your suggestion on the grounds that, as they stand, Date
> objects represent exact points in time, with no ambiguities, and in many
> cases that's exactly what you need. Once you endow them with a timezone
> offset they cease to represent points in time, but rather more points in
> space, which adds complexity and liability to any code handling Date
> objects - similar to how any code expecting integral Numbers has to be
> prepared for non-integral input.
>
> It's unfortunate that the boat has sailed on Date, because it's actually a
> very inappropriate name for what it is. But what I think is really needed
> is another distinct class for Date+Time components. You would project a
> Date to its components (incl a tz offset, to avoid ambiguity around DST
> shifts) for a given timezone, and with those components, answer the kinds
> of questions you have. No arithmetic should be possible with such a
> class, short of extracting a Date back from it and working on that.
>
> On Friday, 5 August 2016, Jordan Harband  wrote:
>
>> This message was in my Gmail spam folder due to "It has a from address in
>> yahoo-inc.com but has failed yahoo-inc.com's required tests for
>> authentication." - so it's possible nobody saw it.
>>
>> Replying all to bump.
>>
>> On Fri, Jul 29, 2016 at 12:51 PM, Juan Dopazo 
>> wrote:
>>
>>> Hello,
>>>
>>> I’ve been working on Yahoo Mail and we’ve been running into multiple
>>> issues with timezones. Currently EcmaScript supports only creating Date
>>> objects with the User Agent’s timezone. However, we need to be able to
>>> operate with whatever timezone our users selected in their settings page.
>>> In most cases we just need to render dates with the correct timezone and
>>> this is currently available using the Ecma 402 APIs. However, in other
>>> cases we need to make certain computations taking into account an arbitrary
>>> timezone and this is not covered by either EcmaScript or Ecma 402.
>>>
>>> In particular, we need to answer the following questions:
>>>
>>>- Is a certain date in the current day/month/year? This means given
>>>a Date object, is it in the current day for an arbitrary timezone?
>>>- When is the start of the day/month for this timezone?
>>>
>>> Currently the only way to answer these questions is by calculating the
>>> timezone offset for the timezone around the date we’re studying. And the
>>> way to do that is to render a date using Intl.DateTimeFormat and recreate a
>>> date object: https://gist.github.com/juando
>>> pazo/b52820e368739ed19cb206e3f3893166.
>>>
>>> Ideally, EcmaScript would allow developers to operate on a Date object
>>> for an arbitrary timezone. Would date.setTimezone(/* IANA string identifier
>>> */) work? I know it’s a problem that is in the middle between EcmaScript
>>> and Ecma 402.
>>>
>>> Thank you,
>>>
>>> Juan Dopazo
>>>
>>>
>>> ___
>>> 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: improve import syntax

[Kris Siegel]

The syntax could stay the same while adding the other way as well. Yes it
adds a complication but I don't know that auto complete friendliness was
considered when adding the original syntax.

You can't really say the editor is the problem because there are cases in
which an editor can't realistically guess where the imported item will be
coming from for an auto complete but with the suggested changes it could as
Ali suggests.

I would say making the syntax more auto complete friendly should be a topic
to explore. Makes it easier for developers (which should be the goal of
almost all standard changes).

On Jul 31, 2016 11:50 AM, "Frankie Bagnardi"  wrote:

> It's too late to change the import syntax. The problem is your editor, not
> the syntax. Over time more editors will support import syntax, either
> directly or with plugins. For now, you just have to wait.
>
> On Sun, Jul 31, 2016 at 3:38 AM, Ali Ghanavatian <
> ghanavatian@gmail.com> wrote:
>
>> Hello there,
>> I am writing to express weak point currently affects the import syntax.
>> As you know current syntax is not editor (specially auto-complete) friendly
>> as editor would not have any clue about what is about to be imported and
>> from where.
>>
>> import { ComponentName } from 'path/to/module-file';
>>
>>
>> My suggestion is to add support for this syntax:
>>
>> from 'path/to/module-file' import { ComponentName };
>>
>>
>> Which makes auto-completion and development easier.
>>
>> I think it deserves a proposal, but it's my first idea. I really
>> appreciate any sort of guidance and suggestion about this issue and how to
>> put it into the standard.
>>
>> --
>>  Sincerely
>> A. Ghanavatian 
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Splitting the "Standard Library" from the EcmaScript spec

[Kris Siegel]

I love this idea. I was originally hoping to champion a whole slew of
additions to the JavaScript Standard Library because I'd really love for a
set of standard ways to do much of what we use private APIs today (lack of
time to follow up on my original thread).

I'm not sure how it works out logistically though with ECMA. But a
separation at least makes sense to me (especially if we start adding a lot
to the standard library which I know many are against but like Python I
think it would be a huge boon to the JavaScript community).

I don't think import foo from std is the worst idea either but that would
be breaking unless we put it under "use stricter" or something similar.

On Jul 28, 2016 10:02 AM, "John Lenz"  wrote:

> A fair amount of text in the EcmaScript spec is spent on defining the
> EcmaScript standard classes and methods.  This has the side-effect of doing
> two things:
>
>   - encouraging standard classes/methods to have special behavior
>   - discouraging creating appropriate "building blocks"
>
> How differently would EcmaScript have been defined if Map, WeakMap,
> Promise, etc were only defined in terms of a "core" language.   Would we
> have a standard identity hash code? A concept of time?
>
> Many of the existing Array.prototype methods, etc could be moved to
> "Library" project that could be defined in terms of an implementation
> rather than step-by-step spec language.
>
> To be clear, I'm not proposing a different delivery mechanism (aka "import
> foo from std") but simply a change to the evolutionary process to encourage
> a clean separation.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Bind Promise Catch to Try/Catch scope

[Kris Siegel]

So I understand the proposal what exactly is `window.callback.getCatch()`?

Is window the reference to the global object created in a browser context?
Since this group is for ECMAScript discussions referencing window, I think,
would be out of the question in this scope (perhaps more appropriate as a
WHATWG recommendation).

Or is window simply holding the callback yourself using (so essentially
removing the reference to `window` would keep your proposal the same)? If
so functions in ECMAScript can hold properties and other functions so this
could create a collision.

If the ultimate goal of this proposal is to allow the try catch pattern to
work across asynchronously executed code then I think await is really your
answer here. I think anything else may be a bit too complex though I'm
certainly open to hearing any ideas (not that my opinion technically
matters in that regard ).

On Tue, Jun 21, 2016 at 6:49 PM, Todd Hubers 
wrote:

> Good questions Tab
>
> 1. Mixtures of async/await and callback code. As much as you want purity
> it doesn't always happen.
> 2. Related to the previous question. Those who have mixtures of
> async/await and callback code.
>
> I've used await a lot in C#/.NET, it isn't the cure of the diagnosed
> callback disease, but it is a great treatment. In some coding scenarios I
> have found the await keyword to be more cumbersome than callbacks. This
> could be due to the way C# implements it - all functions which await must
> return a Task object, and if the method is decorated with async, it must
> await. In .Net it's multithreaded and not an event loop by default, so it
> can be more complicated. I was building a TCP server recently with C# and
> gave up, ripped out all the async/await and replaced with callbacks. It was
> so much easier.
>
> I don't have academic references handy which would back up my claim that
> "await doesn't solve all async problems, and can actually work against you
> in some scenarios in ES". Perhaps there are others who can support me on
> this front.
>
>
>
> Sent with MailTrack
> 
>
> Regards,
>
> Todd Hubers (BBIT Hons)
> Software Engineer
>
> Contact  | Availability
> 
>
> On 22 June 2016 at 11:37, Tab Atkins Jr.  wrote:
>
>> On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers 
>> wrote:
>> > 1. Whether you await or not, the try scope's catch callback [TSCC]
>> should still be captured.
>>
>> Why? Async code doesn't do anything special for try/catch anywhere
>> else in the language - what does this proposal do that's worth the
>> added complexity beyond what just using a Promise and the await/async
>> keywords can do?
>>
>> > 2. If there is no use of Promise (for coders own design reasons) the
>> try scope's catch callback [TSCC] should be available
>>
>> What uses are you thinking of, and why should this be available?
>>
>> ~TJ
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Has there been any discussions around standardizing socket or file io usage?

[Kris Siegel]

I didn't see this in the archives but I was curious if any consideration
has been given for standardizing on features more commonly found in most
other language's standard library.

For example reading and writing to sockets in JavaScript requires platform
specific libraries and works very differently between them. The same goes
for file io (which would obviously need restrictions when run in, say, a
web browser).

Building these in would make JavaScript more universal and easier to learn
(you learn one way to access a resource instead of 2 or 3 very different
ways).

I would be happy to work on a proposal for such changes if they were
desired by the community. Thoughts?

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