Propose simpler string constant

2015-12-15 Thread Kip Obenauf 
A common pattern I see is this:
const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'

Would it be helpful to allow a shorter version of this to be:
const ADD_ALL_THE_STUFF

Rather than have that just be forever undefined, it could automatically
refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

2015-12-15 Thread Jordan Harband 
That seems hazardous - if someone is converting a "var" codebase to "const"
and "let", and they convert `var foo;` to `const foo;` expecting it to be
undefined, the current TDZ error will be much more helpful to them than a
silent change of meaning in their code to `const foo = 'foo';`.

On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf  wrote:

> A common pattern I see is this:
> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>
> Would it be helpful to allow a shorter version of this to be:
> const ADD_ALL_THE_STUFF
>
> Rather than have that just be forever undefined, it could automatically
> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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

2015-12-15 Thread Isiah Meadows 
Or at least something that can come next iteration. At least the spec is
written :)

All that's left is the endless bikeshedding over the syntax :D (Hasn't it
been like a few months people have been debating syntax?)

On Mon, Dec 14, 2015, 11:13 Kevin Smith  wrote:

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

Re: Propose simpler string constant

2015-12-15 Thread Brendan Eich 
What's wanted is `enum { APPLE, ORANGE, GRAPE }` instead.

Turns out `enum` was one of four Java-ish future reserved words that IE
actually reserved from the ancient days. So we could use it. Some
half-formed talk of using it to define categorical sum types, and even
value types -- i.e., allowing constructors for the parts of sum, and other
operations a la methods.

/be

On Tue, Dec 15, 2015 at 11:45 AM Jordan Harband  wrote:

> That seems hazardous - if someone is converting a "var" codebase to
> "const" and "let", and they convert `var foo;` to `const foo;` expecting it
> to be undefined, the current TDZ error will be much more helpful to them
> than a silent change of meaning in their code to `const foo = 'foo';`.
>
> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf 
> wrote:
>
>> A common pattern I see is this:
>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>
>> Would it be helpful to allow a shorter version of this to be:
>> const ADD_ALL_THE_STUFF
>>
>> Rather than have that just be forever undefined, it could automatically
>> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>
>> ___
>> 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: Propose simpler string constant

2015-12-15 Thread Andrea Giammarchi 
Jordan AFAIK you can't have undefined const declaration so your concern is
unfounded.

However, I'm pretty sure what Brendan says **is** indeed what developers
want so I'd +1 that without problems.

Regards

On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband  wrote:

> That seems hazardous - if someone is converting a "var" codebase to
> "const" and "let", and they convert `var foo;` to `const foo;` expecting it
> to be undefined, the current TDZ error will be much more helpful to them
> than a silent change of meaning in their code to `const foo = 'foo';`.
>
> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf 
> wrote:
>
>> A common pattern I see is this:
>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>
>> Would it be helpful to allow a shorter version of this to be:
>> const ADD_ALL_THE_STUFF
>>
>> Rather than have that just be forever undefined, it could automatically
>> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>
>> ___
>> 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: Propose simpler string constant

2015-12-15 Thread Alexander Jones 
TypeScript has this already, so I'm sure we can learn a thing or two from
their implementation.

On 15 December 2015 at 19:56, Andrea Giammarchi  wrote:

> Jordan AFAIK you can't have undefined const declaration so your concern is
> unfounded.
>
> However, I'm pretty sure what Brendan says **is** indeed what developers
> want so I'd +1 that without problems.
>
> Regards
>
> On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband  wrote:
>
>> That seems hazardous - if someone is converting a "var" codebase to
>> "const" and "let", and they convert `var foo;` to `const foo;` expecting it
>> to be undefined, the current TDZ error will be much more helpful to them
>> than a silent change of meaning in their code to `const foo = 'foo';`.
>>
>> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf 
>> wrote:
>>
>>> A common pattern I see is this:
>>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>>
>>> Would it be helpful to allow a shorter version of this to be:
>>> const ADD_ALL_THE_STUFF
>>>
>>> Rather than have that just be forever undefined, it could automatically
>>> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

2015-12-15 Thread Jordan Harband 
Correct, when `const foo;` throws, my concern doesn't exist. The concern I
was talking about is if this initial suggestion went through, and `const
foo;` would become `const foo = 'foo';`, that a new refactoring hazard
would be created - which is the entire reason `const foo;` throws as-is.

Agreed that an `enum` construct would be very useful.

On Tue, Dec 15, 2015 at 11:56 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Jordan AFAIK you can't have undefined const declaration so your concern is
> unfounded.
>
> However, I'm pretty sure what Brendan says **is** indeed what developers
> want so I'd +1 that without problems.
>
> Regards
>
> On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband  wrote:
>
>> That seems hazardous - if someone is converting a "var" codebase to
>> "const" and "let", and they convert `var foo;` to `const foo;` expecting it
>> to be undefined, the current TDZ error will be much more helpful to them
>> than a silent change of meaning in their code to `const foo = 'foo';`.
>>
>> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf 
>> wrote:
>>
>>> A common pattern I see is this:
>>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>>
>>> Would it be helpful to allow a shorter version of this to be:
>>> const ADD_ALL_THE_STUFF
>>>
>>> Rather than have that just be forever undefined, it could automatically
>>> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>>
>>> ___
>>> 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: Propose simpler string constant

2015-12-15 Thread kdex 

Honestly,

```js
const ADD_ALL_THE_STUFF = "ADD_ALL_THE_STUFF";
```

doesn't seem like a intended approach anyway, even if there was a 
shorter syntax. `Symbol()` seems to be the better choice if the 
objective is to manage references whose values indicates special 
semantics; I have yet to see a use case where a string turns out to be 
beneficial. Semantically, what should


```js
typeof (enum {
APPLE,
ORANGE,
GRAPE
}).APPLE;
```

evaluate to? A `"symbol"` called with its identifier, an 
identifier-valued `"string"`, an integer-valued `"number"`?


On 16.12.2015 00:00, Jordan Harband wrote:
Correct, when `const foo;` throws, my concern doesn't exist. The 
concern I was talking about is if this initial suggestion went 
through, and `const foo;` would become `const foo = 'foo';`, that a 
new refactoring hazard would be created - which is the entire reason 
`const foo;` throws as-is.


Agreed that an `enum` construct would be very useful.

On Tue, Dec 15, 2015 at 11:56 AM, Andrea Giammarchi 
> wrote:


Jordan AFAIK you can't have undefined const declaration so your
concern is unfounded.

However, I'm pretty sure what Brendan says **is** indeed what
developers want so I'd +1 that without problems.

Regards

On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband > wrote:

That seems hazardous - if someone is converting a "var"
codebase to "const" and "let", and they convert `var foo;` to
`const foo;` expecting it to be undefined, the current TDZ
error will be much more helpful to them than a silent change
of meaning in their code to `const foo = 'foo';`.

On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf
> wrote:

A common pattern I see is this:
const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'

Would it be helpful to allow a shorter version of this to be:
const ADD_ALL_THE_STUFF

Rather than have that just be forever undefined, it could
automatically refer to a string of the same name, i.e.
'ADD_ALL_THE_STUFF'.

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



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





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


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