Re: New Promise Syntax Proposal

[Jonathan Barronville]

@T.J. Crowder: Interestingly, in this case, it looks like the
`readline` module’s [`@question(…)`
API](https://nodejs.org/docs/v9.0.0/api/readline.html#readline_rl_question_query_callback)
doesn’t even use the usual Node.js-style callback, which is what
[`util.promisify`](https://nodejs.org/docs/v9.0.0/api/util.html#util_util_promisify_original)
expects …

On Mon, Nov 6, 2017 at 10:43 AM, T.J. Crowder
 wrote:
> On Mon, Nov 6, 2017 at 3:39 PM, Jorge Téllez
>  wrote:
>> Yes, I’ll be happy to provide a concrete example.
>
> Very useful example!
>
> In that scenario I'd convert to promises *early*, by promisifying the
> `interface.question` function once (using [`util.promisify`][1] or
> roll-your-own if needed), and then using the promisified version throughout
> (which lets you use `async` functions).
>
> -- T.J. Crowder
>
> [1]: https://nodejs.org/api/util.html#util_util_promisify_original



-- 
- Jonathan

—

Life is a game and we’re all just high density pixels.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Promise Syntax Proposal

[Jonathan Barronville]

>From the example provided, as someone who uses promises a lot, I’m not sure
I’m sold on the need for this either. Maybe you could provide some more
concrete examples, Jorge?


P.S. Proposals like this are why JavaScript should’ve been a LISP ;p …

On Mon, Nov 6, 2017 at 10:28 AM, Isiah Meadows 
wrote:

> I'm not convinced of the need. Promises are already sufficient, and in
> general use, I rarely use the constructor outside of adapting
> callback-related code or other lower-level cases.
>
> Also, keep in mind, most such promise-returning functions do have
> arguments, which this proposal seems to miss.
>
> On Mon, Nov 6, 2017, 10:23 Jorge Téllez  wrote:
>
>> I would like to propose a new syntax for promises for the next ECMAScript.
>>
>> It is common to define promises in the following way:
>>
>> function promiseFunction() {
>>   return new Promise(resolve, reject) {
>> resolve(someValue);
>>   };
>> }
>>
>> In the previous example, I am declaring a function so that I can access
>> the promise throughout.
>>
>> I would like propose a simpler syntax to remove this redundancy:
>>
>> promise promiseFunction(resolve, reject) {
>>   resolve(someValue);
>> }
>>
>> This will make the promise declaration easier to read in a similar
>> fashion as the new class syntax made it easier to declare prototypes.
>>
>> __
>> Jorge Téllez
>> +52 1 81 2567 8257 <+52%201%2081%202567%208257>
>> @novohispano 
>>
>> ___
>> 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
>
>


-- 
- Jonathan

—

Life is a game and we’re all just high density pixels.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Filtered Promise#catch

[Jonathan Barronville]

__@Christopher Thorn:__ I do see your point, but as pointed out by
__Peter Jaszkowiak__, there are already several little facilities
which have been added to JavaScript that are actually useful but could
relatively easily/straightforwardly be implemented in userland. This
particular feature (*i.e.*, filtered catch) is a very useful one that
I, like __Peter Jaszkowiak__ and likely lots of other folks, find
myself using *a lot*. In fact, there are at least a couple projects
where I've wanted to use Bluebird just due to the usefulness of that
feature alone and how clean it allows my code to be. Of course, we
don't want to add every potentially useful feature to the language,
but I think a case like this is a perfect example of when it makes
sense (*IMHO*).

On Wed, Oct 11, 2017 at 12:10 AM, Peter Jaszkowiak  wrote:
> True, it's a fairly trivial thing, but so is `Array.prototype.includes`. I
> can give a hundred other examples.
>
> There is a reason that so many people use underscore, ramda, lodash, etc:
> the "standard library" in Javascript is incomplete. We should aim to provide
> as many of these helpful utilities as possible. Not only does it improve
> developer experience, it also reduces payloads people need to download over
> the wire.
>
> I can understand why people are hesitant to add _syntactic additions_ to
> JavaScript, but when it comes to such useful cases that are already in wide
> use via libraries, I can't understand the reservations.
>
> You did provide a good method name (`guard`) if the final decision is to
> avoid overloading `catch` (which I don't mind either way, in some ways it
> would be preferable so the argument order could be reversed).
>
> Anyways, I think the best implementation would do three things:
>
> 1. If `matcher` is a function, check if `matcher.prototype instanceof
> Error`, if so, use `instanceof` to check if a rejected error matches
> 2. If `matcher` is a function that doesn't inherit from `Error`, execute it
> with the rejected error to get the match condition
> 3. If `matcher` is an object, check every own enumerable property against
> the rejected error to get the match condition
>
> This seems pretty complicated, in that it doesn't seem to match the
> principle of avoiding overloading in the standard library. I think in this
> case, removing any of this functionality is a significant loss, but if any
> were to be removed, I'd choose #3.
>
> Regards,
> Peter
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
- Jonathan

—

Life is a game and we’re all just high density pixels.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Filtered Promise#catch

[Jonathan Barronville]

Yes, *+1*. Filtered .catch(…)

is
a *Bluebird* feature that I use *quite a lot*. Native support would be
great. I’ve personally only ever needed to use the constructor matcher
version (*i.e.*, the version which uses instanceof under the hood), but I
can see why support for the other versions (object predicate and function
predicate) could be useful.

On Tue, Oct 10, 2017 at 7:06 PM, Peter Jaszkowiak 
wrote:

> Excuse me if this has been discussed previously, I did try to find
> existing discussions.
>
> Bluebird has very useful functionality in `Promise.prototype.catch`, which
> allows for filtering certain error types. Here is an example:
>
> ```js
> database.get('user:Bob')
>   .catch(UserNotFoundError, (err) => {
> console.error('User not found: ', err);
>   })
> ```
>
> Which is a shortcut for the following:
>
> ```js
> database.get('user:Bob')
>   .catch((err) => {
> if (err instanceof UserNotFoundError) {
>   console.error('User not found: ', err);
>   return;
> }
>
> throw err;
>   })
> ```
>
> I think this would be a huge improvement to error handling in asynchronous
> situations, especially since many people dislike using `try { ... } catch
> (e) { ... }` syntax (which would also benefit from some sort of error
> filtering).
>
> ### Options
>
> I think that passing in the matching argument as the second argument is
> preferable to passing it as the first argument, but in the spririt of
> compatibility, supporting it in the Bluebird fashion is best.
> Alternatively, a new prototype method (like `catchFilter` or `error`) could
> be used to instead support the same functionality.
>
> Terminology:
> - Callback
>   The function passed as the next operation in the chain, to be called if
> a rejection occurs
> - Matcher
>   The argument passed to select a certain type of error to be caught, and
> then execute the provided callback
>
>  Use `instanceof`
> The class or constructor would be passed as the matcher
>
> This on its own is  It would not support instances from other contexts,
> nor would it support custom errors created without subclassing (like
> manually setting error.name).
>
> Example
> ```js
> const err = new CustomError();
> Promise.reject(err)
>   .catch(CustomError, (customError) => {
> // handle CustomError s
>   })
>   .catch((otherError) => {
> // handle other errors
>   });
> ```
>
>  Use pattern matching
> An object would be passed as the matcher, and it's own enumerable
> properties would be compared with properties of the error instance. If all
> properties on the given matcher are strictly equal to the same properties
> on the error instance, it's a match.
>
> Example:
> ```js
> const err = new Error();
> err.name = 'CustomError';
> Promise.reject(err)
>   .catch({ name: 'CustomError' }, (customError) => {
> // handle CustomError s
>   })
>   .catch((otherError) => {
> // handle other errors
>   });
> ```
>
> This would allow for matching any error type, and could support a subset
> of the `instanceof` check by doing something like `{ constructor:
> CustomError }`.
>
>  Use a matcher function
> A function would be passed as the matcher, receiving the err as its
> argument. It would then be able to do any operation on the error instance
> to check if it is the correct error type.
>
> Example:
> ```js
> const err = new Error();
> err.name = 'CustomError';
> Promise.reject(err)
>   .catch(err => (err.name === 'CustomError'), (customError) => {
> // handle CustomError s
>   })
>   .catch((otherError) => {
> // handle other errors
>   });
> ```
>
> However, this is almost no different from just including the tests in the
> catch body itself. It's verbose enough that the benefit of supporting this
> is not nearly as significant than the other options.
>
>  Support `instanceof` and pattern matching
> In my opinion, this is the best of both worlds. You get to support the
> basic `instanceof` case with inheritance, etc, while also supporting
> matching more custom errors made in a less standard manner.
>
> The method would check if the matcher is a function, and if so, it would
> use `instanceof`. Otherwise, it would treat the argument as an object and
> compare the properties.
>
>
> ### Example Naive Polyfill
>
> ```js
> const origCatch = Promise.prototype.catch;
> Promise.prototype.catch = { catch (ErrorType, callback) {
>   if (typeof callback !== 'function' && typeof ErrorType === 'function') {
> callback = ErrorType;
> ErrorType = null;
>   }
>
>   if (!ErrorType || !(typeof ErrorType === 'object' || typeof ErrorType
> === 'function')) {
> return origCatch.call(this, callback);
>   }
>
>   // if the ErrorType is a function, use instanceof
>   if (typeof ErrorType === 'function') {
> return origCatch.call(this, (err) => {
>   if (err instanceof ErrorType) {
> return 

Re: AND and OR in if statement

[Jonathan Barronville]

No, please don't do this. While I understand why you want this, I feel like
this is unnecessary and will just introduce yet another way to write
inconsistent and confusing JavaScript code .  
  
\- Jonathan  
  
—  
  
Life is a game and we’re all just high density pixels.  

On May 24 2016, at 9:15 pm, Francis Clavette
clavette.fran...@gmail.com wrote:  

> Hi,  

>

> I’d like to be able to use AND for  and OR for || in conditional
statements in a future version of ECMAScript. It’s a feature I’ve always been
wanting since transitioning from PHP. It’s also much cleaner :  
  
if ($scope.newSourceModal.isShown()  $scope.newsource.type == "book"
 (!$scope.insertingFromScan || $scope.ok))  
  
==  
  
if ($scope.newSourceModal.isShown() AND $scope.newsource.type == "book" AND
(!$scope.insertingFromScan OR $scope.ok))  
  
  

>

> Francis  

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

Re: Status/Thoughts on Guards?

[Jonathan Barronville]

+1 for https://research.microsoft.com/pubs/224900/safets.pdf ... some
really good research. As Mark said, though, it's more likely we'll get a
fight than anything productive from such a conversation, which is quite
unfortunate :( .

- Jonathan


On Tue, Aug 19, 2014 at 10:52 PM, Mark S. Miller erig...@google.com wrote:

 See also
 http://disnetdev.com/blog/2011/08/23/Contracts.coffee-Contracts-For-JavaScript-and-CoffeeScript/
 and http://research.microsoft.com/apps/pubs/default.aspx?id=224900

 I am a fan of making it notationally easier to inject runtime validation
 of some sort, whether starting from guards or from either of the approaches
 above.

 From discussions at TC39, it is clear that any such proposal would be a
 long fight. I don't know that anyone is willing to invest the time needed
 to lead that fight. I know I'm not -- it is unlikely to bubble to the top
 of my priority queue.




 On Tue, Aug 19, 2014 at 7:00 PM, Curtis Steckel stec...@squareup.com
 wrote:

 I've been spending time lately writing a lot of repeated validation code
 for function parameters and using popular object schema validation
 libraries like Joi (https://github.com/hapijs/joi) which led me to
 re-reading and thinking about strawman:guards (
 http://wiki.ecmascript.org/doku.php?id=strawman:guards.

 **I'm curious what TC39 and the es-discuss' current thoughts and
 attitudes towards guards is at the moment.**

 They seem to come up every once in a while in TC39 notes, but usually
 only through a tangential mention followed by a mix of that would
 eliminate the possibility of guards, guards could work, let's talk
 about something else (not guards).

 I see that Dave Herman seems to have some opinions on guards and
 obviously Waldemar has ideas (given his activity on the straw man). Anyone
 else?

 ___
 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: Math.TAU

[Jonathan Barronville]

NO! π all the things!
Just kidding ;) ... +1 adding the τ constant.

- Jonathan


On Sat, Jun 28, 2014 at 9:01 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:

 I'll admit to being a pi-ist, rather than a tau-ist, but I don't object to
 adding Math.TAU.  It's a fairly harmless easter egg.
   --scott


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


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

Re: Specifics of `class` and `super`

[Jonathan Barronville]

Hi James.

Take a look here: 
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-makesuperreference-propertykey-strict
 .
I think that should help you.

- Jonathan Barronville

On December 9, 2013 at 10:54:54 AM, James Long (longs...@gmail.com) wrote:

Hey guys,  

First posting to this mailing list. I'm defining a few ES6 features as  
sweet.js macros so existing projects can easily leverage them. I also  
happen to think macros are a big deal for JS and this is how future  
extensions should be defined... (at least ones that are mostly  
syntactic) My project is here: https://github.com/jlongster/es6-macros  

I'm working on `class`, and it's mostly working. You can see the tests  
here: https://github.com/jlongster/es6-macros/blob/master/tests/class.sjs,  
and the generated code here:  
https://github.com/jlongster/es6-macros/blob/master/tests/class.js  

My question is with `super`. I've searched the archives and read the  
spec to answer most of my questions, but one thing is unclear. What  
exactly is the scope of `super`? Is it valid to use `super` inside a  
nested function, like in this example?  
https://github.com/jlongster/es6-macros/blob/master/tests/class.sjs#L91  

If so, `super` seems somewhat magical in that it can resolve the  
prototype of a `this` object that isn't available (when that function  
is called, `this` is not the object anymore). Are there clear rules  
with how `super` is resolved somewhere?  

Thanks,  
James  
___  
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

Refinements.

[Jonathan Barronville]

Hi everyone.

I have a proposal for ES6. I don't know if it's been discussed before, so if it 
has, I don't mean to waste your time … hopefully, I'll be directed to the right 
place.

One of the most debated JavaScript topics (at least in my experience) is 
whether or not one should modify objects that don't belong to them ... some say 
it's okay if you know what you're doing and others see it as a crime.

I propose we solve this problem by adding refinements to ES6. Ruby v2.0.0 
introduced a nice little feature dubbed refinements. Refinements allow you to 
extend other objects for specific modules of code. I know this isn't a Ruby 
mailing list, but because the inspiration comes from the Ruby implementation, 
an example is in order (feel free to ignore it).

Say you want to modify the `to_str()` method in the built-in String class in 
Ruby, the common way to do this is as follows.

```ruby
class String
  def to_str()
    Blah, blah, blah ... this is an example.
  end
end
```

Very simple ... just re-open the class and create a method with the same name. 
However, there's a problem with this, which happens to be the same problem we 
have in JavaScript, and that's the fact that we've now just modified this 
method permanently for the rest of the execution.

Well, with refinements, the better way of accomplishing the same thing is as 
follows.

```ruby
module MyLibrary
  refine(String) do
    def to_str()
      Blah, blah, blah ... this is an example.
    end
  end
end
```

Now, if you try to send `to_str()` to, say, a string object `hello` 
(`hello.to_str()`), you'll get the original `hello` as a return value. In 
order to use the refinements made to the class, you have to do the following.

```ruby
using MyLibrary

puts(hello.to_str())
```

Running the code above properly outputs the string `Blah, blah, blah ... this 
is an example.`.

Refinements can only be used after a `using` statement and only within that 
file.

Given that we're already getting modules in ES6, I believe something similar to 
this would be a great addition to the language.

I can definitely work on a more in-depth and detailed proposal, with specific 
JavaScript examples, if needed, but I just would like to hear thoughts around 
the idea.

Thanks!

- Jonathan Barronville
@jonathanmarvens

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

Refinements.

[Jonathan Barronville]

Hi everyone.

I have a proposal for ES6. I don't know if it's been discussed before, so if it 
has, I don't mean to waste your time … hopefully, I'll be directed to the right 
place.

One of the most debated JavaScript topics (at least in my experience) is 
whether or not one should modify objects that don't belong to them ... some say 
it's okay if you know what you're doing and others see it as a crime.

I propose we solve this problem by adding refinements to ES6. Ruby v2.0.0 
introduced a nice little feature dubbed refinements. Refinements allow you to 
extend other objects for specific modules of code. I know this isn't a Ruby 
mailing list, but because the inspiration comes from the Ruby implementation, 
an example is in order (feel free to ignore it).

Say you want to modify the `to_str()` method in the built-in String class in 
Ruby, the common way to do this is as follows.

```ruby
class String
  def to_str()
    Blah, blah, blah ... this is an example.
  end
end
```

Very simple ... just re-open the class and create a method with the same name. 
However, there's a problem with this, which happens to be the same problem we 
have in JavaScript, and that's the fact that we've now just modified this 
method permanently for the rest of the execution.

Well, with refinements, the better way of accomplishing the same thing is as 
follows.

```ruby
module MyLibrary
  refine(String) do
    def to_str()
      Blah, blah, blah ... this is an example.
    end
  end
end
```

Now, if you try to send `to_str()` to, say, a string object `hello` 
(`hello.to_str()`), you'll get the original `hello` as a return value. In 
order to use the refinements made to the class, you have to do the following.

```ruby
using MyLibrary

puts(hello.to_str())
```

Running the code above properly outputs the string `Blah, blah, blah ... this 
is an example.`.

Refinements can only be used after a `using` statement and only within that 
file.

Given that we're already getting modules in ES6, I believe something similar to 
this would be a great addition to the language.

I can definitely work on a more in-depth and detailed proposal, with specific 
JavaScript examples, if needed, but I just would like to hear thoughts around 
the idea.

Thanks!

- Jonathan Barronville
@jonathanmarvens

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

Re: Refinements.

[Jonathan Barronville]

Sure thing Rick, I will definitely do that.

I'd love to hear any current thoughts and feedback around the idea though.

Thanks!

- Jonathan Barronville
@jonathanmarvens

On October 21, 2013 at 1:26:57 AM, Rick Waldron (waldron.r...@gmail.com) wrote:




On Sun, Oct 20, 2013 at 9:01 AM, Jonathan Barronville jonat...@belairlabs.com 
wrote:
Hi everyone.

I have a proposal for ES6. I don't know if it's been discussed before, so if it 
has, I don't mean to waste your time … hopefully, I'll be directed to the right 
place.

One of the most debated JavaScript topics (at least in my experience) is 
whether or not one should modify objects that don't belong to them ... some say 
it's okay if you know what you're doing and others see it as a crime.

I propose we solve this problem by adding refinements to ES6. Ruby v2.0.0 
introduced a nice little feature dubbed refinements. Refinements allow you to 
extend other objects for specific modules of code. I know this isn't a Ruby 
mailing list, but because the inspiration comes from the Ruby implementation, 
an example is in order (feel free to ignore it).

Say you want to modify the `to_str()` method in the built-in String class in 
Ruby, the common way to do this is as follows.

```ruby
class String
  def to_str()
    Blah, blah, blah ... this is an example.
  end
end
```

Very simple ... just re-open the class and create a method with the same name. 
However, there's a problem with this, which happens to be the same problem we 
have in JavaScript, and that's the fact that we've now just modified this 
method permanently for the rest of the execution.

Well, with refinements, the better way of accomplishing the same thing is as 
follows.

```ruby
module MyLibrary
  refine(String) do
    def to_str()
      Blah, blah, blah ... this is an example.
    end
  end
end
```

Now, if you try to send `to_str()` to, say, a string object `hello` 
(`hello.to_str()`), you'll get the original `hello` as a return value. In 
order to use the refinements made to the class, you have to do the following.

```ruby
using MyLibrary

puts(hello.to_str())
```

Running the code above properly outputs the string `Blah, blah, blah ... this 
is an example.`.

Refinements can only be used after a `using` statement and only within that 
file.

Given that we're already getting modules in ES6, I believe something similar to 
this would be a great addition to the language.

I can definitely work on a more in-depth and detailed proposal, with specific 
JavaScript examples, if needed, but I just would like to hear thoughts around 
the idea.

Thanks!

I think this idea is certainly worth writing a strawman for, but it's too late 
in the ES6 cycle and this couldn't even be considered until ES7. Would you be 
willing to write up a Refinements strawman with some proposed ES-centric 
syntax and some preliminary semantics sketched? 

Rick


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

Refinements.

[Jonathan Barronville]

Hi everyone.

I have a proposal for ES6. I don't know if it's been discussed before, so if it 
has, I don't mean to waste your time … hopefully, I'll be directed to the right 
place.

One of the most debated JavaScript topics (at least in my experience) is 
whether or not one should modify objects that don't belong to them ... some say 
it's okay if you know what you're doing and others see it as a crime.

I propose we solve this problem by adding refinements to ES6. Ruby v2.0.0 
introduced a nice little feature dubbed refinements. Refinements allow you to 
extend other objects for specific modules of code. I know this isn't a Ruby 
mailing list, but because the inspiration comes from the Ruby implementation, 
an example is in order (feel free to ignore it).

Say you want to modify the `to_str()` method in the built-in String class in 
Ruby, the common way to do this is as follows.

```ruby
class String
  def to_str()
    Blah, blah, blah ... this is an example.
  end
end
```

Very simple ... just re-open the class and create a method with the same name. 
However, there's a problem with this, which happens to be the same problem we 
have in JavaScript, and that's the fact that we've now just modified this 
method permanently for the rest of the execution.

Well, with refinements, the better way of accomplishing the same thing is as 
follows.

```ruby
module MyLibrary
  refine(String) do
    def to_str()
      Blah, blah, blah ... this is an example.
    end
  end
end
```

Now, if you try to send `to_str()` to, say, a string object `hello` 
(`hello.to_str()`), you'll get the original `hello` as a return value. In 
order to use the refinements made to the class, you have to do the following.

```ruby
using MyLibrary

puts(hello.to_str())
```

Running the code above properly outputs the string `Blah, blah, blah ... this 
is an example.`.

Refinements can only be used after a `using` statement and only within that 
file.

Given that we're already getting modules in ES6, I believe something similar to 
this would be a great addition to the language.

I can definitely work on a more in-depth and detailed proposal, with specific 
JavaScript examples, if needed, but I just would like to hear thoughts around 
the idea.

Thanks!

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