Re: Map literal

[Isiah Meadows]

That's something no one here really thought of yet. I don't personally have
a lot of investment in this.

(@Alex and yes, much of that was based on your idea. It was a great
starting point.)

On Thu, Oct 29, 2015, 21:23 Alexander Jones  wrote:

> I don't think borrowing object notation is a good idea. What exactly does
>
> ```
> const myMap = Map#{
> get foo() { return 100; },
> set foo(v) {}
> constructor() {}
> };
> ```
>
> mean?
>
> Honestly, a very significant portion of the use cases I have for *actual
> maps* don't involve string keys. So to borrow object notation and have to
> constantly write keys in [] is pretty naff:
>
> ```
> const describe = Dict#{
> [1]: "one",
> [[1, 2]]: "array of 1 and 2",
> [null]: "the null value",
> }; // please no!
> ```
>
> If it makes people feel too weird to have comma separated, colon split
> key-value pairs within curlies that *don't* parse like POJSOs, we could
> have completely non-ambiguous parse with normal parentheses, I think?
>
> ```
> const describe = Dict#(
> 1: "one",
> [1, 2]: "array of 1 and 2",
> null: "the null value",
> );
> ```
>
> That might limit confusion while giving a syntactically clean way to
> define maps. Let's consider that a future mapping type like Dict compares
> non-primitive keys by abstract value instead of by reference identity.
> There are *tonnes* of nice use cases that open up that are taken for
> granted in other languages and other classes like Immutable.Map - we're not
> there yet with ES6 built-ins, so perhaps people might not yet appreciate
> the value of this.
>
> To reiterate a previous point, object property access with a statically
> defined string key is idiomatically written `obj.foo`, so it makes sense
> for symmetry to have `foo` appear as a bareword in a literal defining `obj
> = {foo: 42}`. For most mapping-type classes this symmetry simply does not
> apply, and frankly neither should it.
>
> Also, I specifically suggested that the consumed value is an ArrayIterator
> rather than an Array, because I feel having an intermediate Array around is
> placing too high an importance on the humble Array. If the implementation
> really wants an Array to work on internally, they can simply call
> `Array.from` with little cost. But if they want an Immutable.List they can
> have that instead without ever seeing an actual Array. (The Symbol.fromHash
> method is just Symbol.literalOf as I called it - same thing, modulo
> bikeshed.)
>
> Alex
>
>
> On 29 October 2015 at 22:51, Isiah Meadows  wrote:
>
>> Why not make it desugar to a direct function call with a single array of
>> pairs? It's so parsed as a regular object, so shorthands can still be used.
>>
>> `Map#{foo: 1, bar: 2, 3: "baz"}`
>> `Map[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>>
>> `Object#{foo: 1, bar: 2, 3: "baz"}`
>> `Object[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>>
>> `Object.null#{foo: 1, bar: 2, 3: "baz"}`
>> `Object.null[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>>
>> (`bar` doesn't have [[Construct]])
>> `Object#{foo, bar() {}}`
>> `Object[Symbol.fromHash]([[foo", foo], ["bar", function () {}]])`
>>
>> And as for implementation, use this:
>>
>> ```js
>> extend class Map {
>>   static [Symbol.fromHash](pairs) {
>> return new this(pairs);
>>   }
>> }
>>
>> // etc...
>>
>> function SetKeys(target, pairs) {
>>   for (const [key, value] of pairs) {
>>   target[key] = value
>> }
>> return target
>> }
>>
>> extend class Object {
>>   static [Symbol.fromHash](pairs) {
>> return SetKeys({}, pairs)
>>   }
>>
>>   static null(pairs) {
>> return SetKeys(Object.create(null), pairs)
>>   }
>> }
>> ```
>>
>> Pretty simple IMHO. A helper decorator could even be made.
>>
>> On Wed, Oct 28, 2015, 14:34 Alexander Jones  wrote:
>>
>>> Also I would like to reiterate that errors in the shape of the N-by-2
>>> array are only caught at runtime. That's really not ideal.
>>>
>>> On Wednesday, 28 October 2015, Dave Porter 
>>> wrote:
>>>
 I don’t love any of the specific suggestions so far, but saving 3 + 2n
 keystrokes isn't the point – readability and learnability are. Visually,
 `new Map([[‘foo’, 42]])` is a mess.

 On Oct 28, 2015, at 9:28 AM, Michał Wadas 
 wrote:

 Difference between any proposed here syntax and current state ( new
 Map([ [1,2], [2,3] ]); ) is..

 3 characters + 2 characters/entry.




 2015-10-28 17:22 GMT+01:00 Mohsen Azimi :

> When I look at `Map#{"foo": 42}` I don't see much difference with `new
> Map([['foo', 42]])`.
>
> Since you can pass expressions there, it's already possible to do it
> with current syntax. There is only a bunch of extra brackets(`[` and `]`)
> that I don't like.
>
>
> On Wed, Oct 28, 2015 at 5:51 AM Alexander Jones 

Re: Existential Operator / Null Propagation Operator

[Claude Pache]

> Le 30 oct. 2015 à 11:11, Isiah Meadows  a écrit :
> 
> It's visually ambiguous. I'd rather not read `1..toString()` and `foo..bar` 
> in the same file. Not with greatly differing meanings. 
> 
No, `(1.).toString()` and `(1)..toString()` have strictly the same observable 
effect, so that their formal difference of semantics can be happily ignored.

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

Object Propagation Operator (was Re: Existential Operator / Null Propagation Operator)

[Isiah Meadows]

It's visually ambiguous, though. I really don't want to be reading
`foo..bar()` and `1..toString()` in the same file. They look the same, but
mean two completely different things.

In a language that has this feature, I almost never use it, anyways, unless
I'm interacting with the DOM. And even then, I'm not saving that much
typing. Not with an editor with tab completion (most do).

On Thu, Oct 29, 2015, 19:29 Claude Pache  wrote:

>
>
> > Le 30 oct. 2015 à 00:07, Waldemar Horwat  a écrit :
> >
> >> On 10/29/2015 14:20, Claude Pache wrote:
> >
> >> In some cases – as in `3..toStrign()` –, `undefined` will be produced
> where an error was thrown.
> >
> >
> > No, this would continue to throw an error.
>
> Oops, you're right. So, `..` is 100% backward-compatible.
>
> —Claude
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object Propagation Operator (was Re: Existential Operator / Null Propagation Operator)

[Isiah Meadows]

Ignore that last email...misremembered the context.

On Fri, Oct 30, 2015, 06:06 Isiah Meadows  wrote:

> It's visually ambiguous, though. I really don't want to be reading
> `foo..bar()` and `1..toString()` in the same file. They look the same, but
> mean two completely different things.
>
> In a language that has this feature, I almost never use it, anyways,
> unless I'm interacting with the DOM. And even then, I'm not saving that
> much typing. Not with an editor with tab completion (most do).
>
> On Thu, Oct 29, 2015, 19:29 Claude Pache  wrote:
>
>>
>>
>> > Le 30 oct. 2015 à 00:07, Waldemar Horwat  a écrit
>> :
>> >
>> >> On 10/29/2015 14:20, Claude Pache wrote:
>> >
>> >> In some cases – as in `3..toStrign()` –, `undefined` will be produced
>> where an error was thrown.
>> >
>> >
>> > No, this would continue to throw an error.
>>
>> Oops, you're right. So, `..` is 100% backward-compatible.
>>
>> —Claude
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

Observable effect doesn't mean same process. Granted, the case with a
number literal is very obscure, anyways, so I'm not that worried about it.

On Fri, Oct 30, 2015, 06:20 Claude Pache  wrote:

> Le 30 oct. 2015 à 11:11, Isiah Meadows  a écrit :
>
> It's visually ambiguous. I'd rather not read `1..toString()` and
> `foo..bar` in the same file. Not with greatly differing meanings.
>
> No, `(1.).toString()` and `(1)..toString()` have strictly the same
> observable effect, so that their formal difference of semantics can be
> happily ignored.
>
> —Claude
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

It's visually ambiguous. I'd rather not read `1..toString()` and `foo..bar`
in the same file. Not with greatly differing meanings.

On Thu, Oct 29, 2015, 19:29 Claude Pache  wrote:

>
>
> > Le 30 oct. 2015 à 00:07, Waldemar Horwat  a écrit :
> >
> >> On 10/29/2015 14:20, Claude Pache wrote:
> >
> >> In some cases – as in `3..toStrign()` –, `undefined` will be produced
> where an error was thrown.
> >
> >
> > No, this would continue to throw an error.
>
> Oops, you're right. So, `..` is 100% backward-compatible.
>
> —Claude
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Just try

[Michael McGlothlin]

It'd be nice if you could just do try {} without all the catch and finally
stuff because about half the time the logic is simpler if I can just put
all the error handling code in one place at the end. I end up with a lot of
empty catch (err){} laying around waiting to break something. And using one
large try/catch/finally block isn't really workable either because I don't
want an exception to break the flow.

Of course it'd be nice if there was syntax to shorten

let test = undefined;
try {
 test = testSomething();
} catch ( err ) {}

into just

let test = try testSomething() || undefined;

Possibly where without the `|| undefined` test would contain an Error
instance that's flagged as thrown or such. An Error flagged as thrown
should evaluate as false so that logic ops work.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: resolve()/reject() on Promise subclasses and @@species

[Allen Wirfs-Brock]

+1

Allen

> On Oct 30, 2015, at 10:19 AM, Claude Pache  > wrote:
> 
> 
>> Le 29 oct. 2015 à 03:51, Boris Zbarsky > > a écrit :
>> 
>> I was just implementing subclassing of Promise in Gecko, when I realized 
>> that given a Promise subclass MyPromise these two calls:
>> 
>>  MyPromise.race([])
>>  MyPromise.all([])
>> 
>> will take MyPromise[@@species] into account when creating the return value, 
>> but these two calls:
>> 
>>  MyPromise.resolve()
>>  MyPromise.reject()
>> 
>> will not; they will invoke MyPromise itself, not MyPromise[@@species].
>> 
>> This is because 
>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.all 
>>  and 
>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.race 
>>  do the 
>> whole @@species thing but 
>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.reject 
>>  and 
>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve 
>>  do not.
>> 
>> Is this behavior intentional?  If so, I'd really like to understand the 
>> reason for it.
>> 
>> -Boris
> 
> Relevant discussion: https://esdiscuss.org/topic/performpromiseall 
> 
> 
> As I understand, the specified behaviour is an accident of history. 
> Previously, `Promise.resolve()` and `Promise.reject()` used the species 
> pattern in order to determine the constructor to be used, just as 
> `Promise.all()` and `Promise.race()`. Then, at the last minute, it was 
> decided that it wasn’t the best semantics for `Promise.resolve()`, and it was 
> corrected. For `Promise.all()` and `Promise.race()`, the motivation wasn’t 
> stronger than the lack of time.
> 
> Should it be corrected before @@species is widely implemented? I think so. 
> The arguments I give are:
> 
> * Overall consistency in the language. Except for the two offending Promise 
> static methods, all uses of `@@species` in the ES2015 spec (15 uses) are for 
> the following pattern: Starting from one instance, one constructs a derived 
> object for that instance. (The effective lookup of the @@species property is 
> factored in the SpiecesConstructor and ArraySpeciesCreate abstract 
> operations.)
> 
> * Also, in static methods like `Promise.all` and `Promise.race`, a 
> constructor is explicitly provided by the user: simply use it. Compare with 
> what is done for arrays:
> 
>   Array.from(someArray) // use the Array constructor explicitly provided.
>   Array.of(x, y, z) // ditto
> 
>   someArray.slice(0) // compute the constructor to be used through some 
> algorithm involving @@species.
>   [].concat(x, y, z) // ditto
> 
> —Claude
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org 
> https://mail.mozilla.org/listinfo/es-discuss

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

Re: Just try

[Mohsen Azimi]

This would be nice with `await` but how would you specify the boundary?

```
let json = try await (await fetch('file'.json).json());
```
should that throw on `.json()` now?

On Fri, Oct 30, 2015 at 6:48 AM Michael McGlothlin <
mike.mcgloth...@gmail.com> wrote:

> It'd be nice if you could just do try {} without all the catch and finally
> stuff because about half the time the logic is simpler if I can just put
> all the error handling code in one place at the end. I end up with a lot of
> empty catch (err){} laying around waiting to break something. And using one
> large try/catch/finally block isn't really workable either because I don't
> want an exception to break the flow.
>
> Of course it'd be nice if there was syntax to shorten
>
> let test = undefined;
> try {
>  test = testSomething();
> } catch ( err ) {}
>
> into just
>
> let test = try testSomething() || undefined;
>
> Possibly where without the `|| undefined` test would contain an Error
> instance that's flagged as thrown or such. An Error flagged as thrown
> should evaluate as false so that logic ops work.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: resolve()/reject() on Promise subclasses and @@species

[Claude Pache]

> Le 29 oct. 2015 à 03:51, Boris Zbarsky  a écrit :
> 
> I was just implementing subclassing of Promise in Gecko, when I realized that 
> given a Promise subclass MyPromise these two calls:
> 
>  MyPromise.race([])
>  MyPromise.all([])
> 
> will take MyPromise[@@species] into account when creating the return value, 
> but these two calls:
> 
>  MyPromise.resolve()
>  MyPromise.reject()
> 
> will not; they will invoke MyPromise itself, not MyPromise[@@species].
> 
> This is because 
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.all and 
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.race do the whole 
> @@species thing but 
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.reject and 
> http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve do not.
> 
> Is this behavior intentional?  If so, I'd really like to understand the 
> reason for it.
> 
> -Boris

Relevant discussion: https://esdiscuss.org/topic/performpromiseall 


As I understand, the specified behaviour is an accident of history. Previously, 
`Promise.resolve()` and `Promise.reject()` used the species pattern in order to 
determine the constructor to be used, just as `Promise.all()` and 
`Promise.race()`. Then, at the last minute, it was decided that it wasn’t the 
best semantics for `Promise.resolve()`, and it was corrected. For 
`Promise.all()` and `Promise.race()`, the motivation wasn’t stronger than the 
lack of time.

Should it be corrected before @@species is widely implemented? I think so. The 
arguments I give are:

* Overall consistency in the language. Except for the two offending Promise 
static methods, all uses of `@@species` in the ES2015 spec (15 uses) are for 
the following pattern: Starting from one instance, one constructs a derived 
object for that instance. (The effective lookup of the @@species property is 
factored in the SpiecesConstructor and ArraySpeciesCreate abstract operations.)

* Also, in static methods like `Promise.all` and `Promise.race`, a constructor 
is explicitly provided by the user: simply use it. Compare with what is done 
for arrays:

Array.from(someArray) // use the Array constructor explicitly provided.
Array.of(x, y, z) // ditto

someArray.slice(0) // compute the constructor to be used through some 
algorithm involving @@species.
[].concat(x, y, z) // ditto

—Claude

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

Re: resolve()/reject() on Promise subclasses and @@species

[Kevin Smith]

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

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

Re: Just try

[Michał Wadas]

Syntax sugar similar to Go error handling would be much more useful, at
least for me :

let [err, result] = try JSON.parse('invalid');
On Oct 30, 2015 5:33 PM, "Mohsen Azimi"  wrote:

> This would be nice with `await` but how would you specify the boundary?
>
> ```
> let json = try await (await fetch('file'.json).json());
> ```
> should that throw on `.json()` now?
>
> On Fri, Oct 30, 2015 at 6:48 AM Michael McGlothlin <
> mike.mcgloth...@gmail.com> wrote:
>
>> It'd be nice if you could just do try {} without all the catch and
>> finally stuff because about half the time the logic is simpler if I can
>> just put all the error handling code in one place at the end. I end up with
>> a lot of empty catch (err){} laying around waiting to break something. And
>> using one large try/catch/finally block isn't really workable either
>> because I don't want an exception to break the flow.
>>
>> Of course it'd be nice if there was syntax to shorten
>>
>> let test = undefined;
>> try {
>>  test = testSomething();
>> } catch ( err ) {}
>>
>> into just
>>
>> let test = try testSomething() || undefined;
>>
>> Possibly where without the `|| undefined` test would contain an Error
>> instance that's flagged as thrown or such. An Error flagged as thrown
>> should evaluate as false so that logic ops work.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Just try

[Alican Çubukçuoğlu]

The recommended way of checking for file existence in Node.js is calling
`fs.stat()` on the file. If no error was passed to the callback, it exists.
If "ENOENT" was passed, it doesn't.

If you "promisify" `fs.stat()` and use it with async/await, it throws when
a file doesn't exist so you end up writing a lot of try/catches. You say
"Hey, it would be great if I didn't have to keep writing `catch(e){}`." but
what if the error wasn't "ENOENT"?

That's why I withdrew myself from suggesting such a thing. Carelessly
silencing errors is no good.

I like the idea of `let stuff = try something()` putting the error in
`stuff` but the problem is you can throw strings in JavaScript:

```
function getUserName() {
  throw 'Error';
}

const userName = try getUserName();

if (userName instanceof Error) {
  handleError(userName);

  return;
}

console.log('There was no error, yay!');
// Actually there was
```

---

Also `try stuff() || undefined` will not be evaluated to `undefined` on
error:
```
> var err = new Error('Stuff blew up!');
undefined
> err || undefined
[Error: Stuff blew up!]
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: resolve()/reject() on Promise subclasses and @@species

[Boris Zbarsky]

On 10/30/15 1:19 PM, Claude Pache wrote:

Should it be corrected before @@species is widely implemented?


Or implemented at all?  Chrome doesn't implement it yet.  My Firefox 
tree does for Promise as of today, but I could just as easily drop it 
from all/race if people prefer that.


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