Re: Exponentiation operator precedence

[Herby Vojčík]

Claude Pache wrote:


I just wonder why it is important that unary binds tighter? For
instance, before I carefully studied the issue of this thread, I have
never expected that unary minus binds tighter than binary multiplication
operator in expressions like `-2*x` (although it does not matter in that
case).

Making the parentheses mandatory here will be somewhat annoying in
perfectly reasonable expressions, where you usually don’t use
parentheses in real math notation., like:
```
let s2 = - x**2 - y**2 - z**2 + t**2
```


I would overcome it and do not write the parens:

  let s2 = 0 - x**2 - y**2 - z**2 + t**2

Writing mandatory parens here is ugly.

In fact, I am surprised "-2" is unary minus with 2, I thought it is 
number -2. And similarly to Claude, I always read -x*y in math notation, 
that is, as -(x*y). Luckily, for multiplication it does not matter.


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

Re: Exponentiation operator precedence

[Herby Vojčík]

Herby Vojčík wrote:



Claude Pache wrote:


I just wonder why it is important that unary binds tighter? For
instance, before I carefully studied the issue of this thread, I have
never expected that unary minus binds tighter than binary multiplication
operator in expressions like `-2*x` (although it does not matter in that
case).

Making the parentheses mandatory here will be somewhat annoying in
perfectly reasonable expressions, where you usually don’t use
parentheses in real math notation., like:
```
let s2 = - x**2 - y**2 - z**2 + t**2
```


I would overcome it and do not write the parens:

let s2 = 0 - x**2 - y**2 - z**2 + t**2


An off-topic thought: Unary minus (and plus) are only used with numbers 
in JS. Why are they treated specially, not as hidden 0+x and 0-x, 
respectively? That would be logical (unary plus and minus would have 
same precendence as binary plus and minus).



Writing mandatory parens here is ugly.

In fact, I am surprised "-2" is unary minus with 2, I thought it is
number -2. And similarly to Claude, I always read -x*y in math notation,
that is, as -(x*y). Luckily, for multiplication it does not matter.

Herby
___
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: Exponentiation operator precedence

[Brendan Eich]

Because C (B, BCPL, Algol). Too late to change JS where people do tricks
such as !-x. No win in risking compat break.

/be
On Fri, Sep 25, 2015 at 4:18 AM Herby Vojčík  wrote:

>
>
> Herby Vojčík wrote:
> >
> >
> > Claude Pache wrote:
> >>
> >> I just wonder why it is important that unary binds tighter? For
> >> instance, before I carefully studied the issue of this thread, I have
> >> never expected that unary minus binds tighter than binary multiplication
> >> operator in expressions like `-2*x` (although it does not matter in that
> >> case).
> >>
> >> Making the parentheses mandatory here will be somewhat annoying in
> >> perfectly reasonable expressions, where you usually don’t use
> >> parentheses in real math notation., like:
> >> ```
> >> let s2 = - x**2 - y**2 - z**2 + t**2
> >> ```
> >
> > I would overcome it and do not write the parens:
> >
> > let s2 = 0 - x**2 - y**2 - z**2 + t**2
>
> An off-topic thought: Unary minus (and plus) are only used with numbers
> in JS. Why are they treated specially, not as hidden 0+x and 0-x,
> respectively? That would be logical (unary plus and minus would have
> same precendence as binary plus and minus).
>
> > Writing mandatory parens here is ugly.
> >
> > In fact, I am surprised "-2" is unary minus with 2, I thought it is
> > number -2. And similarly to Claude, I always read -x*y in math notation,
> > that is, as -(x*y). Luckily, for multiplication it does not matter.
> >
> > Herby
> > ___
> > 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: Fix Left-Associative Compound Conditional Statements!!

[Isiah Meadows]

I think the main issue with this idea, based on that thread, is the burden
of proof it won't break the Web. No one seems to have actually tested it,
yet. I don't know of any obfuscators that emit that from a transform (they
only emit it if that was in the input), so my heuristic is that it likely
won't break 90% of sites, but even then, 10% of the Internet broken is
still far too breaking.

Also, as a side note, -1 on the exclamation points for the subject.

On Thu, Sep 24, 2015, 12:16 Joseph Groseclose  wrote:

> At some length I see, heh. Alright, I guess that just about sums it up.
>
> On Thu, Sep 24, 2015 at 11:01 AM, Claude Pache 
> wrote:
>
>> For an old discussion on the same subject, see:
>>
>>
>> https://esdiscuss.org/topic/chained-comparisons-from-python-and-coffeescript
>>
>> —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.clone - not quite a proposal

[Isiah Meadows]

I'll also point out that cloning DOM elements generally won't work as
intended because DOM implementations sometimes tack on hidden properties
that aren't even seen by the engine. Also, I know that V8 adds hidden
properties to objects, which would have to be transferred as well.

And this is where persistent data structures become useful... (I recently
dropped Mori into a project because I was dealing with a ton of immutable
data, but I still wanted it to be lightweight, and I didn't need all the
bells and whistles of Immutable.js.)

On Thu, Sep 24, 2015, 20:32 Andrea Giammarchi 
wrote:

> Also, one reason I haven't used that, if you clone descriptors you do a
> shallow copy, not a deep one ;-)
>
> On Fri, Sep 25, 2015 at 2:31 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Claude, you know that's actually *my* proposal, right? :P
>> https://gist.github.com/WebReflection/9353781
>>
>> But yeah, that's the spirit!
>>
>> On Thu, Sep 24, 2015 at 8:21 PM, Claude Pache 
>> wrote:
>>
>>>
>>> Le 24 sept. 2015 à 19:58, Andrea Giammarchi 
>>> a écrit :
>>>
>>> Last, but not least, one does not simply assign properties in
>>> JavaScript. If you want to clone you don't want to miss possible get/set
>>> accessors in the process, you don't want to miss getOwnPropertyNames and
>>> getOwnpropertySymbols neither, so the last loop doesn't work as proposal.
>>>
>>> ```js
>>> // simplified version for regular objects only
>>> // basically just the correct substitute of your last temp logic
>>> Object.clone = function (src) {
>>>   return Object.setPrototypeOf(
>>> Reflect.ownKeys(src).reduce((o, k) => {
>>>   var d = Object.getOwnPropertyDescriptor(src, k);
>>>   if (
>>> o.hasOwnProperty.call(d, 'value') &&
>>> /function|object/.test(typeof d.value)
>>>   ) d.value = Object.clone(d.value);
>>>   return Object.defineProperty(o, k, d);
>>> }, {}),
>>> Object.getPrototypeOf(src)
>>>   );
>>> };
>>> ```
>>>
>>>
>>> ```js
>>> Object.clone = function (src) {
>>> return Object.create(Object.getPrototypeOf(src),
>>> Object.getOwnPropertyDescriptors(src))
>>> }
>>> ```
>>>
>>> where  the definition of `Object.getOwnPropertyDescriptors()` is left as
>>> an exercise to the reader.
>>>
>>>
>>> —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: Exponentiation operator precedence

[Marius Gundersen]

One advantage of #4 is that it will make it possible to introduce either #2
or #3 in the future, if we change our minds. This way we can use real world
use cases to decide if we should go for #2 or #3.

Marius Gundersen

On Fri, Sep 25, 2015 at 1:23 AM, Waldemar Horwat 
wrote:

> My preference is for 2, but I don't have objections to 4.  Either works.
>
> Waldemar
>
> ___
> 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