Re: Can we improve async JavaScript error handling?
We already have a construct that automatically returns a promise, which
resolves on return and rejects on throw. It's called an async function!
On Nov 30 2019, at 7:05 am, Lars Eidnes wrote:
> Currently when awaiting calls there's some surprising behavior when combining
> throw/catch and reject/resolve.
>
> ```js
> function resolveAndThrow() {
> return new Promise((resolve, reject) => {
> resolve("huh");
> throw new Error(""); //<-- this throw is executed
> });
> }
> async function callAsync() {
> try {
> await resolveAndThrow();
> } catch (e) {
> console.log("caught error", e); //<-- yet, this is error logging never happens
> }
> }
> ```
>
> Here the error logging doesn't happen, because resolve() is called before the
> throw, which causes the thrown error to be swallowed. Specifically, the throw
> executes, and control flow is broken, but control flow never moves to the
> catch {} block. This is a sort of dark corner, where language mechanisms
> interact in conflicting ways. Most programmers wont have at top-of-mind which
> of resolve and throw will "win" in a situation like the one above. In fact, I
> suspect most JavaScript programmers haven't thought about this issue at all
> until they encounter it.
>
> I've written a longer post about this error handling issue in JavaScript some
> time ago: https://catchjs.com/Docs/AsyncAwait . There I mention how C# has
> async/await, but does not have reject/resolve, and thus doesn't really have
> this issue. There, exceptions thrown in async operations get transferred to
> the whomever is awaiting the Task, and whatever is returned from the Task is
> returned to whomever is awaiting it. So throw serves the purpose of reject(),
> and return serves the purpose of resolve().
>
> This is nice. It makes the reject/resolve mechanisms redundant, and removes
> the paradoxical resolve+throw case shown above. Really, this possible because
> the main interface for creating something awaitable (e.g. Task.Run(() => {})
> ) is more similar to setTimeout than to new Promise(). Is it possible to
> introduce similar mechanisms to JavaScript?
>
> For reference, C# Tasks can be used like this:
>
> ```
> var result = await Task.Run(() => { Thread.Sleep(2); return 1; });
> //result now holds 1
>
> try {
> var result2 = await Task.Run(() => {
> throw new Exception(""); //This error is tracked across execution boundaries
> return 1;
> });
> } catch (Exception e) {
> Console.WriteLine(e); //This error logging happens, with a full stack trace
> from the await to the throw.
> }
> ```
>
> The lack of resolve/reject has the benefit that there is no chance of messing
> up with mixing throw and resolve. A key thing here is that thrown exceptions
> are transported across execution contexts to wherever the Task is awaited.
>
> The reason we have reject/resolve, as far as I can see, is to be able to
> transport values and errors across execution context, for example so that one
> can do this:
>
> ```js
> function resolveInSetTimeout() {
> return new Promise((resolve, reject) => {
> setTimeout(() => resolve(1), 100);
> });
> }
> async function callAsync() {
> var result = await resolveInSetTimeout(); //result now holds 1
> }
> ```
>
> In JavaScript, the place where an API similar to Task could be useful would
> be as a replacement for setTimeout(callback). Some new API that takes a
> callback, returns a Promise, and where thrown errors in the callback are
> transported back to anyone awaiting the Promise, and where returned values in
> the callback resolve the Promise. It seems to me that transporting the thrown
> error across execution boundaries requires language/runtime support, at least
> if we want to get proper stack traces.
>
> If libraries with async APIs were built on this mechanism, we could use them
> and ensure that we can do error tracking for any errors happening inside
> setTimeouts. Now we're at the mercy of the library author remembering to
> catch the error and passing it to reject().
>
> I've written a lot here, and I suspect this mailing list is better equipped
> than I am to figure out what's a good idea in this context. Two questions to
> summarize:
>
> 1) Is it a good idea to introduce an alternative to setTimeout, where the
> distinction is that it returns a Promise, and that return/throw in the
> callback take the role of resolve/reject?
>
> 2) Are there other things we could do to minimize the need for resolve/reject?
>
> What do you think?
>
> ___
> 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: What do you think about a C# 6 like nameof() expression for
You've already made this point, so you're not adding anything new to the
discussion now. Especially since your point seems to be "I don't understand"
and "it won't help me personally"
It's time to take a step back and allow others to discuss. If a formal proposal
eventuates, you can continue to make your points there
On Jun 20 2019, at 11:05 am, guest271314 wrote:
> The current proposal is redundant. The user has to already know and write the
> exact name of the variable, or try to guess the variable name to not, or to,
> catch an error that includes the name of the identifier as a string. Why
> should the user have to already know any write the variable as a literal? If
> that feature is valuable to users of JavaScript by all means write that
> definition.
>
> Extending the original proposal with the ability for the user to use
> ```nameof``` to get list of all varibales declared using ```const``` and
> ```let``` without having to already know and write the exact variable name,
> that is, when called without an adjacent exact variable identifier, e.g.,
> ```const nameofall = nameof *; // ["y", "x"] which can also include line
> number```, as well, would not be redundant, and would also benefit users of
> JavaScript directly where defining the feature would provide values that are
> not currently possible (without previously knowing and writing the exact name
> of the variable identifier, or guessing the names of the identifiers, which
> should be also already be possible).
> On Wed, Jun 19, 2019 at 6:31 PM Isiah Meadows (mailto:isiahmead...@gmail.com)> wrote:
> > I get yet again that the forest here is being missed for the trees.
> >
> > @guest271314 This isn't specific to any one IDE, and isn't even
> > specific to static tools. As mentioned before, this has applicability
> > to assertion libraries (like a userland version of Power Assert) as
> > well as other things. It's almost exclusively just quality-of-life
> > improvements to developers, but it's not specific to IDEs or even
> > static tooling.
> >
> > -
> > Isiah Meadows
> > cont...@isiahmeadows.com (mailto:cont...@isiahmeadows.com)
> > www.isiahmeadows.com (http://www.isiahmeadows.com)
> >
> > On Mon, Jun 17, 2019 at 8:28 PM guest271314 > (mailto:guest271...@gmail.com)> wrote:
> > >
> > >
> > > > You have ignored the context from Jordan’s email (emphasis added):
> > >
> > >
> > >
> > > >> again, `Object.keys({ y })[0]` will give you the string `y`, and will
> > > >> survive refactoring tools. you can even do `function nameof(obj) {
> > > >> return Object.keys(obj)[0]; }` and then `nameof({ y })`.
> > >
> > >
> > > No, did not _ignore_ the context of the email.
> > >
> > >
> > > Simply have no reference point for relying on an external tool, that is,
> > > essentially a text editor, to write and dynamically "refactor" code.
> > > Here, the code will be tested outside of the text editor in short order
> > > once composed.
> > >
> > >
> > > Was able to rename text at Mousepad and record the entire process within
> > > 20 seconds without needing to use ```nameof``` and without encountering
> > > any issues such as mispelling the variable name or the text editor trying
> > > to independently determine what the words am typing mean. The text editor
> > > is just - a text editor.
> > >
> > >
> > > Perhaps other JavaScript users who rely on "refactoring tools" and
> > > "rename refactoring" in an IDE can relate. Not able to gather the
> > > significance of ```nameof``` here - as in each case the user has to write
> > > the name of the variable anyway. To each their own.
> > >
> > >
> > > > VSCode is a popular editor that supports JavaScript *and* is a
> > > > refactoring tool. Rename refactoring was the subject I was responding
> > > > to.
> > >
> > >
> > >
> > >
> > >
> > > Was not previously aware or did not realize that the _individual choice_
> > > to use a particular text editor was a substantial reason to ask for
> > > change to the entire JavaScript language in order for specific users to
> > > be able to interact with an entirely different language.
> > >
> > >
> > > If VSCode is particularly "popular" why cannot VSCode be specified and
> > > implemented by and for the users who rely on the text editor to interpret
> > > what the users' intent is when writing code.
> > >
> > >
> > > In that case ```mkvmerge``` should be specified as a JavaScript method.
> > > ```webm``` is a "popular" (cannot help but to recollect "Popularity"
> > > https://brendaneich.com/2008/04/popularity/) video container that is a
> > > subset of the Matroska container, where if that method were specified in
> > > JavaScript a user would be able to do ```mkvmerge({w: true, o:
> > > "int_all.webm": i: ["int.webm", "int1.webm", "intN.webm"]})```
> > > instead of ```$ mkvmerge -w -o int_all.webm int.webm + int1.webm``` at
> > > ```terminal```.
> > >
> > >
> > >
> > >
> > > On Mon, Jun 17, 2019 at 11:29 PM Ron Buckton > > (
Re: Re: What do you think about a C# 6 like nameof() expression for
> > your examples are all completely incorrect anyway
> "incorrect" as to precisely what?
Keep reading the email mate.
Incorrect as to your understanding of how the language works and at what point
variables are defined.
> The user MUST _already_ know the _exact_ identifier name
It's not an issue to need to know the name of the identifier. In fact, as you
correctly pointed out, it's necessary.
If I'm understanding it correctly, the value of the proposal is to make it
easier to refactor (especially with variable renaming tools) without leaving
behind string literals that no longer match the variable name.
I've run into this issue before, but it's been a relatively minor pain for me
personally. So I can see some use for the proposal, though I suspect it would
see most of it's use in tooling.
On the other hand, it might add unnecessary complexity to the language, which
should be avoided.
Overall I'm very mildly supportive.
> That leaves the use case of getting ALL of the names of the identifiers in
> the current scope
I have not seen anyone proposing this, so there's no reason to criticize it yet.
Obligatory disclaimer: not a TC39 member, no decision making power or influence
on process
On Jun 17 2019, at 2:42 pm, guest271314 wrote:
> The user MUST _already_ know the _exact_ identifier name or an error will be
> thrown for the original proposal and additional use case for ```nameof```
>
> const x = nameof y; // "y"
> const y = 1;
> making the need for ```nameof``` moot given that the user cannot then
> rationally state that the identifier as a _string_ will somehow be mispelled
> if they are able to write the _exact_ name of the identifer at ```nameof```
> 100% of the time.
>
> That leaves the use case of getting ALL of the names of the identifiers in
> the current scope
>
> // NAMEOF is always dynamic list of let, const declarations in current scope
> console.log(NAMEOF); // ["x", "y"]; [{name:"x", line:5}, {name:"y", line:7}]
> // should resolve be in the list even if not declared using const or let?
> await new Promise(resolve => setTimeout(resolve, Math.floor(Math.random() *
> 1000)));
> const x = nameof y
> await new Promise(resolve => setTimeout(resolve, Math.floor(Math.random() *
> 1000)));
> const y = 1;
>
> without having to already know the name of the identifiers, as is required by
> the original proposal, which essentially negates itself as the string literal
> ```'y'``` is briefer than ```nameof y```.
>
>
> On Mon, Jun 17, 2019 at 4:19 AM Frederick Stark (mailto:coagm...@gmail.com)> wrote:
> > guest271314, your examples are all completely incorrect anyway since all
> > variable declarations (including let and const) are hoisted to the top of
> > the scope, so when nameof y is evaluated, y is already declared in the
> > scope.
> >
> > The special behaviour introduced with let and const is that they set up a
> > "Temporal Dead Zone" where attempts to set or get their value before the
> > line where they are declared in code throws an exception.
> > Since nameof doesn't care about the value, only the name of the variable,
> > it would not need to throw an exception.
> > Of course, were this proposal to be taken seriously, it could be specced
> > either way
> >
> >
> > On Jun 17 2019, at 10:15 am, guest271314 > (mailto:guest271...@gmail.com)> wrote:
> > > > - If `y` is directly visible in scope and is neither a parameter or
> > > destructured binding, `nameof y` should just evaluate to `"y"`. This
> > > should be agnostic to whether the binding has been declared yet, so in
> > > your example, `x` should be set to `"y"`.
> > >
> > > The 1st question at
> > > https://esdiscuss.org/topic/what-do-you-think-about-a-c-6-like-nameof-expression-for#content-33
> > > remains:
> > >
> > > Without having composed or previously read the source code, at line 1
> > > adjacent to ```nameof``` how does the user know that there will be later
> > > declared variable named ```y```?
> > >
> > >
> > >
> > > On Sun, Jun 16, 2019 at 7:04 AM Isiah Meadows > > (mailto:isiahmead...@gmail.com)> wrote:
> > > > Here's my opinion:
> > > >
> > > > - If `y` is directly visible in scope and is neither a parameter or
> > > > destructured binding, `nameof y` should just evaluate to `"y"`. This
> > > > should be agnostic to whether the binding has been declared yet, so in
> > > > your example, `x`
Re: Re: What do you think about a C# 6 like nameof() expression for
guest271314, your examples are all completely incorrect anyway since all variable declarations (including let and const) are hoisted to the top of the scope, so when nameof y is evaluated, y is already declared in the scope. The special behaviour introduced with let and const is that they set up a "Temporal Dead Zone" where attempts to set or get their value before the line where they are declared in code throws an exception. Since nameof doesn't care about the value, only the name of the variable, it would not need to throw an exception. Of course, were this proposal to be taken seriously, it could be specced either way On Jun 17 2019, at 10:15 am, guest271314 wrote: > > - If `y` is directly visible in scope and is neither a parameter or > destructured binding, `nameof y` should just evaluate to `"y"`. This > should be agnostic to whether the binding has been declared yet, so in > your example, `x` should be set to `"y"`. > > The 1st question at > https://esdiscuss.org/topic/what-do-you-think-about-a-c-6-like-nameof-expression-for#content-33 > remains: > > Without having composed or previously read the source code, at line 1 > adjacent to ```nameof``` how does the user know that there will be later > declared variable named ```y```? > > > > On Sun, Jun 16, 2019 at 7:04 AM Isiah Meadows (mailto:isiahmead...@gmail.com)> wrote: > > Here's my opinion: > > > > - If `y` is directly visible in scope and is neither a parameter or > > destructured binding, `nameof y` should just evaluate to `"y"`. This > > should be agnostic to whether the binding has been declared yet, so in > > your example, `x` should be set to `"y"`. > > - If `y` is entirely undeclared, it should be a runtime > > `ReferenceError` in the same way it is when accessing undefined > > globals. So in your second example, I'd expect it to throw before even > > attempting assignment > > > > - > > Isiah Meadows > > cont...@isiahmeadows.com (mailto:cont...@isiahmeadows.com) > > www.isiahmeadows.com (http://www.isiahmeadows.com) > > > > On Sun, Jun 16, 2019 at 12:00 AM guest271314 > (mailto:guest271...@gmail.com)> wrote: > > > > > > ``` > > > const x = nameof y > > > const y = 1; > > > ``` > > > > > > At line 1 adjacent to ```nameof``` how does the user even know that there > > > is a variable that will be declared named ```y```? > > > > > > What is the output of ```x``` where there is no variable named ```y``` > > > later declared? > > > > > > ``` > > > const x = nameof y > > > const z = 1; > > > ``` > > > > > > On Sun, Jun 16, 2019 at 12:03 AM Ron Buckton > > (mailto:ron.buck...@microsoft.com)> wrote: > > >> > > >> > What should occur where the code is > > >> > > >> It would be "y" in all 3 places. > > >> > > >> > ... is a proposal for _more_ than only getting the _name_ of an > > >> > _declared_ and _initialized_ variable? > > >> > > >> It is a proposal for getting the name of a _declared_ variable. Whether > > >> it is _initialized_ does not matter. > > >> > > >> > Should a ```RefefenceError``` _not_ be thrown simple because > > >> > ```nameof``` is used? > > >> > > >> No, an error is not thrown. ECMAScript is much more nuanced. Block > > >> scoped variables from 'let' or 'const' exist and can be *referenced* > > >> (via closure or export, currently) anywhere within the same block scope, > > >> even before they are initialized. Until they have been *initialized* > > >> (the line of code contain the declaration has been reached and > > >> evaluated), they exist in a "Temporal Dead Zone" (TDZ). Attempting to > > >> *dereference* them (i.e. access or store a value) while in this TDZ is > > >> what results in the ReferenceError. > > >> > > >> At no point does the `nameof` operator *dereference* the variable, so no > > >> error need be thrown. > > >> > > >> From: guest271314 > > >> Sent: Saturday, June 15, 4:29 PM > > >> Subject: Re: Re: What do you think about a C# 6 like nameof() expression > > >> for > > >> To: Ron Buckton > > >> Cc: es-discuss@mozilla.org (mailto:es-discuss@mozilla.org) > > >> > > >> > > >> > > >> > > >> What should occur where the code is > > >> > > >> ``` > > >> const x = nameof y > > >> await new Promise(resolve => setTimeout(resolve, 10)); // should x > > >> be "y" here? > > >> await new Promise(resolve => setTimeout(resolve, 20)); // should x > > >> be "y" here? > > >> await Promise.all([new Promise(resolve => setTimeout(resolve, 30)), > > >> ...doStuff()]); // should x be "y" here? > > >> const y = 1; > > >> ``` > > >> > > >> ? > > >> > > >> The immediately invoked arrow function example (where a > > >> ```RefeferenceError``` is thrown) appears to demonstrate that to output > > >> the expected result of ```nameof``` within the context of the code > > >> example > > >> > > >> ``` > > >> const x = nameof y > > >> const y = 1; > > >> ``` > > >> > > >> is a proposal for _more_ than only getting the _name_ of an _declared_ > > >> and _initialized_ variable? > > >> > > >> Should a `
Re: how many async-modules can js-app practically load?
Pretty sure your issue here is the multiple
Re: Destructuring for Array-like objects
This already works with an iterator, because array destructuring uses the
iterator protocol
const [a, b] = {
0: "ayy",
1: "bee",
length: 2,
*[Symbol.iterator]() {
let i = 0;
while (i < this.length) {
yield this[i]
i++
}
},
};
On Mar 20 2019, at 11:59 am, Sultan wrote:
> Afford array destructuring to Array-like objects.
>
> const [a, b] = {0: a, 1: b, length: 2}
>
> ___
> 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: PSA: You can find existing proposals at https://github.com/tc39/proposals
There's also https://prop-tc39.now.sh/, which is much more readable. It generates it's content by scraping the GitHub pages, so should usually be up to date On Jan 20 2019, at 12:35 pm, Isiah Meadows wrote: > Not TC39, so don't read this as official communication. > > I've lately been seeing the occasional suggestion that's already been > considered by TC39 and accepted, so I just wanted to give a public > service announcement that you can find all the various existing > proposals TC39 has considered (Stage 1-4), as well as many conceptual > proposals that members have created and championed but haven't yet > brought before the committee (Stage 0), here: > https://github.com/tc39/proposals > > That repository includes a few interesting things proposed in the last > few months on this list, such as: > > - Upgraded `switch`: https://github.com/tc39/proposal-pattern-matching > - Stack trace analysis: https://github.com/tc39/proposal-error-stacks > - Placeholder syntax: https://github.com/tc39/proposal-partial-application > - Python `with` syntax: https://github.com/tc39/proposal-using-statement > > So before you propose something, please check there first. You might > find it's already being considered, and if your proposal would differ > significantly from theirs and you feel yours is better, it's best to > give feedback in that proposal's repo, so it's more likely to get > noticed and heard by the appropriate audience. > > - > Isiah Meadows > cont...@isiahmeadows.com > 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: add reverse() method to strings
The point of a coding task for a beginner is to practice their problem solving
skills to solve the task. This would remove the challenge and actively worsen
their learning process
On Mar 18 2018, at 6:26 pm, Grigory Hatsevich wrote:
>
> My use case is solving coding tasks about palindromes on codefights.com. Not
> sure if that counts as "real-world", but probably a lot of beginning
> developers encounter such tasks at least once.
>
>
>
>
> On Sun, 18 Mar 2018 06:41:46 +0700, Mathias Bynens wrote:
> > So far no one has provided a real-world use case.
> >
> > On Mar 18, 2018 10:15, "Mike Samuel" > (https://link.getmailspring.com/link/1521358598.local-593d9031-9a3d-v1.1.5-5834c...@getmailspring.com/0?redirect=mailto%3Amikesamuel%40gmail.com&recipient=ZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZw%3D%3D)>
> > wrote:
> > > Previous discussion:
> > > https://esdiscuss.org/topic/wiki-updates-for-string-number-and-math-libraries#content-1
> > >
> > > (https://link.getmailspring.com/link/1521358598.local-593d9031-9a3d-v1.1.5-5834c...@getmailspring.com/1?redirect=https%3A%2F%2Fesdiscuss.org%2Ftopic%2Fwiki-updates-for-string-number-and-math-libraries%23content-1&recipient=ZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZw%3D%3D)
> > >
> > > """
> > > String.prototype.reverse(), as proposed, corrupts supplementary
> > > characters. Clause 6 of Ecma-262 redefines the word "character" as "a
> > > 16-bit unsigned value used to represent a single 16-bit unit of text",
> > > that is, a UTF-16 code unit. In contrast, the phrase "Unicode character"
> > > is used for Unicode code points. For reverse(), this means that the
> > > proposed spec will reverse the sequence of the two UTF-16 code units
> > > representing a supplementary character, resulting in corruption. If this
> > > function is really needed (is it? for what?), it should preserve the
> > > order of surrogate pairs, as does
> > > java.lang.StringBuilder.reverse:download.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#reverse()
> > >
> > > (https://link.getmailspring.com/link/1521358598.local-593d9031-9a3d-v1.1.5-5834c...@getmailspring.com/2?redirect=http%3A%2F%2Fdownload.oracle.com%2Fjavase%2F7%2Fdocs%2Fapi%2Fjava%2Flang%2FStringBuilder.html%23reverse()&recipient=ZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZw%3D%3D)
> > > """
> > >
> > > On Sat, Mar 17, 2018 at 1:41 PM, Grigory Hatsevich > > (https://link.getmailspring.com/link/1521358598.local-593d9031-9a3d-v1.1.5-5834c...@getmailspring.com/3?redirect=mailto%3Ag.hatsevich%40gmail.com&recipient=ZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZw%3D%3D)>
> > > wrote:
> > > > Hi! I would propose to add reverse() method to strings. Something
> > > > equivalent to the following:
> > > >
> > > > String.prototype.reverse = function(){
> > > > return this.split('').reverse().join('')
> > > > }
> > > >
> > > > It seems natural to have such method. Why not?
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > (https://link.getmailspring.com/link/1521358598.local-593d9031-9a3d-v1.1.5-5834c...@getmailspring.com/4?redirect=mailto%3Aes-discuss%40mozilla.org&recipient=ZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZw%3D%3D)
> > > https://mail.mozilla.org/listinfo/es-discuss
> > > (https://link.getmailspring.com/link/1521358598.local-593d9031-9a3d-v1.1.5-5834c...@getmailspring.com/5?redirect=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Fes-discuss&recipient=ZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZw%3D%3D)
> > >
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: javascript vision thing
I appreciate hearing Kai's point of view and think that we've had this exact discussion enough times. At this point it just adds to inbox weight without changing any minds On Dec 18 2017, at 8:23 am, Terence M. Bandoian wrote: > I appreciate hearing Kai's point of view and don't think he should be > silenced. > > -Terence Bandoian > > > On 12/17/2017 2:03 PM, T.J. Crowder wrote: > > On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband > (mailto:ljh...@gmail.com)> wrote: > > > > > > Adding features in *no way* sacrifices simplicity or ease-of-use > > > for smaller web projects; as has been said many times on this > > > list, if you don't like any new feature, simply choose not to use > > > it. > > > > And in many or even most cases, markedly *improves* simplicity and > > ease-of-use. As has also been repeatedly pointed out. > > > > Kai: Genuine questions are fine. Questions which are really just you > > pushing your agenda of "don't change anything ever again" and your personal > > -- and solitary -- claim that "all this new stuff makes life difficult for > > people" are, at best, pointless. Your position has been made crystal clear. > > There's no need to bang on about it. > > > > -- T.J. Crowder > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How it feels to learn JavaScript in 2016
Best response I've seen: https://medium.freecodecamp.org/javascript-fatigue-fatigue-66ffb619f6ce I'd just like to thank TC39 for not breaking compatibility. All the niche old libraries I use that were written in ES5 still work in my ES6+ projects with no issues. The ability to take it or leave it when it comes to new features makes the changes easy as pie On Oct 28 2017, at 8:26 am, Florian Bösch wrote: > I use a simple build script/requirement/module system I wrote myself in a few > dozen lines that does things the way I like it. I find the permanent churn of > pointless new flavors of the same thing annoying and distracting, whatever > happened to writing code and be done with it, programming isn't spending time > tweaking your super hip setup so long by the time you're done something new > is now the new hotness. > > On Fri, Oct 27, 2017 at 12:38 AM, J Decker (mailto:d3c...@gmail.com)> wrote: > > (humor?) > > https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f > > > > It all seemed so simple > > ___ > > es-discuss mailing list > > es-discuss@mozilla.org (mailto: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: an operator for ignoring any exceptions
Having recently inherited a codebase which silently consumes errors in many
places (using try/catch, Promises that don't reject - just stall, and
promise.catch noops), I can imagine these getting used terribly.
At least with the current operators, there's an expectation in the syntax that
you will handle the error, and you have to make the conscious decision to
ignore the error. Introducing an operator that does it for you implies to
novice programmers that it's an okay thing to do.
The amount of extra code required to ignore the errors is not very onerous, and
if you need it frequently, you can always put it in a wrapper function.
--
Fred Stark
m: 0468 828 420 | e: coagm...@gmail.com
id: keybase.io/coagmano | pgp: 43B91213.asc
I acknowledge the Gadigal people of the Eora Nation, who are the traditional
owners of the land on which I work and live.
On 2 Aug 2017, 2:30 PM +1000, kai zhu , wrote:
> -1
> in my real-world experience, JSON.parse and nodejs fs.readFileSync are the
> only 2 common use-cases that would benefit from this. its more practical to
> use helper-functions for those 2 use-cases rather than change the javascript
> language yet again (besides, returning an empty string is commonly more
> useful for me than returning undefined for failed fs.readFileSync).
> this is also a likely footgun that would get abused by novice programmers for
> many inappropriate use-cases.
> > On Aug 2, 2017 11:59 AM, "Sheng TIAN" wrote:
> > > Is there any proposal for an one unary operator for ignoring any
> > > exceptions.
> > >
> > > (I have not search out any related threads. But it is useful IMO, so I'm
> > > wondering if this had been discussed.)
> > >
> > > For example, we may introduce an unary operator called `try` which
> > >
> > > 1. calculate the operand first
> > > 2. if it not throw, return as is
> > > 3. otherwise return undefined
> > >
> > > This operator may be used when exceptions should always be ignored.
> > >
> > > Example:
> > >
> > > let resp;
> > > try {
> > > resp = JSON.parse(xhr.responseText);
> > > } catch (_ignore) { /* do nothing here */ }
> > >
> > > may be simplified to:
> > >
> > > const resp = try JSON.parse(xhr.responseText);
> > >
> > > Another Example:
> > >
> > > var age = user && user.age;
> > >
> > > to:
> > >
> > > var age = try user.age;
> > >
> > > (Note, in such case, if operand is start with curly braces "{", it must
> > > be wrapped in parentheses "()".)
> > >
> > > ___
> > > 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
