Re: operator overloading proposal

[Kevin Barabash]

> I would prefer syntax + internal slots, since you'll know at creation
time whether the object has overloaded
> operators. It's much simpler for the engine to figure out, and it's more
performant because you only need to
> check one thing instead of worrying about inheritance, own properties,
etc.

Will operators defined on a class work with instances of a subclass?

> Could += be a special case? i.e.,

For sure.  We could define `Symbol.assignPlus`, `Symbol.assignTimes`, etc.
with `u += v;` desugaring to `u = u[Symbol.assignPlus](v)`.  The reason why
we can't do something do `u[Symbol.assignPlus](v)` is that there's no way
to define a method on Number, String, etc. that would reassign their value.

> it appears to me that overloading an operator multiple times (e. g.
unary/binary plus operator) might become
> painful, assuming that the semantics follow the same variadic approach
that regular functions do.

Another pain point is handling cases where you want one class to
interoperate with another.  In one of the example above methods are defined
that allow `Point`s and `Number`s to be added to each other.  In order to
maintain the commutativity of `+` we need to define `operator+` /
`[Symbol.add]` methods on both `Point` and `Number`.  One potential
solution to this problem is create `Symbol.plusRight`, `Symbol.timesRight`
for all of the commutative/symmetric operators.

I feel like this ends up making things more complex because there are more
methods to implement and the methods have to be more complex b/c they have
to do type checking when overloaded.

Maybe `operator+` could work like the `@operator` decorator by calling
`Function.defineOperator` behind the scenes.  In this situation, instead of
methods being added to classes, the `Function` object has well-defined
methods that look up the correct function to call based on the argument
types.  `u + v` desugars to `Function[Symbol.plus](u, v)`.  This is
definitely slower than internal slots, but if we're doing runtime type
checking in the method we may as well have it be automatic.  My hope is to
eventually use static typing (flow b/c I'm using babel) to remove the
lookup cost.


On Tue, May 10, 2016 at 7:07 PM, Isiah Meadows 
wrote:

> You're correct in that the operator doesn't do any type checking (it
> dispatches from its first argument, but that's just traditional OO).
>
> On Tue, May 10, 2016, 20:28 kdex  wrote:
>
>> @Isiah: Comparing your syntax proposal to `Function.defineOperator`, it
>> appears to me that
>> overloading an operator multiple times (e. g. unary/binary plus operator)
>> might become painful,
>> assuming that the semantics follow the same variadic approach that
>> regular functions do.
>>
>> That is, of course, unless you intend to handle all operator overloads in
>> a single `operator +(...args) {}`
>> definition. But then again, something like `Function.defineOperator`
>> seems cleaner and suggests implicit
>> (optional?) type checks with its second argument.
>>
>> On Dienstag, 10. Mai 2016 15:25:32 CEST Isiah Meadows wrote:
>> > Here's my thought, if we go with syntax.
>> >
>> > ```js
>> > class Point {
>> > // constructor, etc.
>> >
>> > operator +(other) {
>> > assert(other instanceof Point)
>> > return new Point(
>> > this.x + other.x,
>> > this.y + other.y)
>> > }
>> >
>> > operator +=(other) {
>> > assert(other instanceof Point)
>> > this.x += other.x
>> > this.y += other.y
>> > }
>> > }
>> > ```
>> >
>> > On Tue, May 10, 2016, 11:16 Brian Barnes  wrote:
>> >
>> > > A note on this from somebody who's entire existence seems dedicated to
>> > > stopping as much stuff as possible from getting GC'd, the example
>> below:
>> > >
>> > >  >const u = new Point(5, 10);
>> > >  >const v = new Point(1, -2);
>> > >  >
>> > >  >const w = u + v;  // desugars to u[Symbol.add](v)
>> > >  >console.log(w);   // { x: 6, y: 8 };
>> > >
>> > > Could += be a special case?  i.e.,
>> > >
>> > > u+=v;
>> > >
>> > > would call:
>> > >
>> > > Class Point { ... other stuff ...
>> > > [whatever the syntax is](pt)
>> > > {
>> > > this.x+=pt.x;
>> > > this.y+=pt.y;
>> > > }
>> > > }
>> > >
>> > > instead of desugaring to:
>> > >
>> > > u=u+v;  // which would cause the creation of an object and
>> > > // leave the other to be collected
>> > >
>> > > For all I know, += might be doing such anyway in some engines, but for
>> > > my stuff which is a lot of 3D math that could be a performance killer.
>> > > It would be nice to be able to just add points and such, as long as
>> the
>> > > overhead is negligible.
>> > >
>> > > [>] Brian
>> > >
>> > > On 5/10/2016 10:52 AM, Isiah Meadows wrote:
>> > > > I would prefer syntax + internal slots, since you'll know at
>> creation
>> > > > time whether the object has overloaded operators. It's much simpler
>> for
>> > > > the engine to figure out, and 

Re: operator overloading proposal

[Isiah Meadows]

You're correct in that the operator doesn't do any type checking (it
dispatches from its first argument, but that's just traditional OO).

On Tue, May 10, 2016, 20:28 kdex  wrote:

> @Isiah: Comparing your syntax proposal to `Function.defineOperator`, it
> appears to me that
> overloading an operator multiple times (e. g. unary/binary plus operator)
> might become painful,
> assuming that the semantics follow the same variadic approach that regular
> functions do.
>
> That is, of course, unless you intend to handle all operator overloads in
> a single `operator +(...args) {}`
> definition. But then again, something like `Function.defineOperator` seems
> cleaner and suggests implicit
> (optional?) type checks with its second argument.
>
> On Dienstag, 10. Mai 2016 15:25:32 CEST Isiah Meadows wrote:
> > Here's my thought, if we go with syntax.
> >
> > ```js
> > class Point {
> > // constructor, etc.
> >
> > operator +(other) {
> > assert(other instanceof Point)
> > return new Point(
> > this.x + other.x,
> > this.y + other.y)
> > }
> >
> > operator +=(other) {
> > assert(other instanceof Point)
> > this.x += other.x
> > this.y += other.y
> > }
> > }
> > ```
> >
> > On Tue, May 10, 2016, 11:16 Brian Barnes  wrote:
> >
> > > A note on this from somebody who's entire existence seems dedicated to
> > > stopping as much stuff as possible from getting GC'd, the example
> below:
> > >
> > >  >const u = new Point(5, 10);
> > >  >const v = new Point(1, -2);
> > >  >
> > >  >const w = u + v;  // desugars to u[Symbol.add](v)
> > >  >console.log(w);   // { x: 6, y: 8 };
> > >
> > > Could += be a special case?  i.e.,
> > >
> > > u+=v;
> > >
> > > would call:
> > >
> > > Class Point { ... other stuff ...
> > > [whatever the syntax is](pt)
> > > {
> > > this.x+=pt.x;
> > > this.y+=pt.y;
> > > }
> > > }
> > >
> > > instead of desugaring to:
> > >
> > > u=u+v;  // which would cause the creation of an object and
> > > // leave the other to be collected
> > >
> > > For all I know, += might be doing such anyway in some engines, but for
> > > my stuff which is a lot of 3D math that could be a performance killer.
> > > It would be nice to be able to just add points and such, as long as the
> > > overhead is negligible.
> > >
> > > [>] Brian
> > >
> > > On 5/10/2016 10:52 AM, Isiah Meadows wrote:
> > > > I would prefer syntax + internal slots, since you'll know at creation
> > > > time whether the object has overloaded operators. It's much simpler
> for
> > > > the engine to figure out, and it's more performant because you only
> need
> > > > to check one thing instead of worrying about inheritance, own
> > > > properties, etc.
> > > >
> > > > Also, it would be IMHO easier to read than a symbol (the computed
> > > > property syntax is ugly IMO). Using a different concept than symbols
> > > > would also fit better with value types whenever any of those
> proposals
> > > > make it into the language (either the struct or special syntax).
> > > >
> > > >
> > > > On Tue, May 10, 2016, 04:03 G. Kay Lee
> > > >  > > > > wrote:
> > > >
> > > > Yes, I think exposing operators through well-known symbols is an
> > > > interesting idea worthy of more exploration because it's
> precisely
> > > > the purpose of well-known symbols to expose and allow
> manipulation
> > > > to previously inaccessible internal language behaviors.
> > > >
> > > > On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash
> > > > > wrote:
> > > >
> > > > > And remember that decorators are essentially just a syntax
> to
> > > > apply functions to objects/classes at design time, so what
> > > > you're proposing is essentially some new global function,
> which
> > > > is going against the current trend and effort to better
> > > > modularize/namespace all these utility functions/methods.
> > > >
> > > > That's a really good point.
> > > >
> > > > > It has been mentioned and discussed in numerous places
> over the
> > > > years, you can find more info on this with some casual
> googling.
> > > > For example:https://news.ycombinator.com/item?id=2983420
> > > >
> > > > Thanks for the link.  I played around with sweet.js a bit
> over
> > > > the weekend.  Using macros should work if we went with Python
> > > > style operator overloading.  Instead of defining methods like
> > > > _ADD_, _SUB_ etc. we could create some well-known symbols,
> maybe
> > > > Symbol.plus, Symbol.times, etc.
> > > >
> > > > ```
> > > > class Point {
> > > >   constructor(x, y) {
> > > > Object.assign(this, {x, y});
> > > >   }
> > > >
> > > >  

Re: operator overloading proposal

[kdex]

@Isiah: Comparing your syntax proposal to `Function.defineOperator`, it appears 
to me that
overloading an operator multiple times (e. g. unary/binary plus operator) might 
become painful,
assuming that the semantics follow the same variadic approach that regular 
functions do.

That is, of course, unless you intend to handle all operator overloads in a 
single `operator +(...args) {}`
definition. But then again, something like `Function.defineOperator` seems 
cleaner and suggests implicit
(optional?) type checks with its second argument.

On Dienstag, 10. Mai 2016 15:25:32 CEST Isiah Meadows wrote:
> Here's my thought, if we go with syntax.
> 
> ```js
> class Point {
> // constructor, etc.
> 
> operator +(other) {
> assert(other instanceof Point)
> return new Point(
> this.x + other.x,
> this.y + other.y)
> }
> 
> operator +=(other) {
> assert(other instanceof Point)
> this.x += other.x
> this.y += other.y
> }
> }
> ```
> 
> On Tue, May 10, 2016, 11:16 Brian Barnes  wrote:
> 
> > A note on this from somebody who's entire existence seems dedicated to
> > stopping as much stuff as possible from getting GC'd, the example below:
> >
> >  >const u = new Point(5, 10);
> >  >const v = new Point(1, -2);
> >  >
> >  >const w = u + v;  // desugars to u[Symbol.add](v)
> >  >console.log(w);   // { x: 6, y: 8 };
> >
> > Could += be a special case?  i.e.,
> >
> > u+=v;
> >
> > would call:
> >
> > Class Point { ... other stuff ...
> > [whatever the syntax is](pt)
> > {
> > this.x+=pt.x;
> > this.y+=pt.y;
> > }
> > }
> >
> > instead of desugaring to:
> >
> > u=u+v;  // which would cause the creation of an object and
> > // leave the other to be collected
> >
> > For all I know, += might be doing such anyway in some engines, but for
> > my stuff which is a lot of 3D math that could be a performance killer.
> > It would be nice to be able to just add points and such, as long as the
> > overhead is negligible.
> >
> > [>] Brian
> >
> > On 5/10/2016 10:52 AM, Isiah Meadows wrote:
> > > I would prefer syntax + internal slots, since you'll know at creation
> > > time whether the object has overloaded operators. It's much simpler for
> > > the engine to figure out, and it's more performant because you only need
> > > to check one thing instead of worrying about inheritance, own
> > > properties, etc.
> > >
> > > Also, it would be IMHO easier to read than a symbol (the computed
> > > property syntax is ugly IMO). Using a different concept than symbols
> > > would also fit better with value types whenever any of those proposals
> > > make it into the language (either the struct or special syntax).
> > >
> > >
> > > On Tue, May 10, 2016, 04:03 G. Kay Lee
> > >  > > > wrote:
> > >
> > > Yes, I think exposing operators through well-known symbols is an
> > > interesting idea worthy of more exploration because it's precisely
> > > the purpose of well-known symbols to expose and allow manipulation
> > > to previously inaccessible internal language behaviors.
> > >
> > > On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash
> > > > wrote:
> > >
> > > > And remember that decorators are essentially just a syntax to
> > > apply functions to objects/classes at design time, so what
> > > you're proposing is essentially some new global function, which
> > > is going against the current trend and effort to better
> > > modularize/namespace all these utility functions/methods.
> > >
> > > That's a really good point.
> > >
> > > > It has been mentioned and discussed in numerous places over the
> > > years, you can find more info on this with some casual googling.
> > > For example:https://news.ycombinator.com/item?id=2983420
> > >
> > > Thanks for the link.  I played around with sweet.js a bit over
> > > the weekend.  Using macros should work if we went with Python
> > > style operator overloading.  Instead of defining methods like
> > > _ADD_, _SUB_ etc. we could create some well-known symbols, maybe
> > > Symbol.plus, Symbol.times, etc.
> > >
> > > ```
> > > class Point {
> > >   constructor(x, y) {
> > > Object.assign(this, {x, y});
> > >   }
> > >
> > >   [Symbol.add](other) {
> > > return new Point(this.x + other.x, this.y + other.y);
> > >   }
> > > }
> > >
> > > const u = new Point(5, 10);
> > > const v = new Point(1, -2);
> > >
> > > const w = u + v;  // desugars to u[Symbol.add](v)
> > > console.log(w);   // { x: 6, y: 8 };
> > > ```
> > >
> > > This would require default implementations to be defined on
> > >

Re: Re: Existential Operator / Null Propagation Operator

[mads . k]

Why isn't it possible to use the obj.property?.sub syntax in combination
with lookahead as suggested by Brendan Eich 4 years ago? 

http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator

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

Re: operator overloading proposal

[Isiah Meadows]

Here's my thought, if we go with syntax.

```js
class Point {
// constructor, etc.

operator +(other) {
assert(other instanceof Point)
return new Point(
this.x + other.x,
this.y + other.y)
}

operator +=(other) {
assert(other instanceof Point)
this.x += other.x
this.y += other.y
}
}
```

On Tue, May 10, 2016, 11:16 Brian Barnes  wrote:

> A note on this from somebody who's entire existence seems dedicated to
> stopping as much stuff as possible from getting GC'd, the example below:
>
>  >const u = new Point(5, 10);
>  >const v = new Point(1, -2);
>  >
>  >const w = u + v;  // desugars to u[Symbol.add](v)
>  >console.log(w);   // { x: 6, y: 8 };
>
> Could += be a special case?  i.e.,
>
> u+=v;
>
> would call:
>
> Class Point { ... other stuff ...
> [whatever the syntax is](pt)
> {
> this.x+=pt.x;
> this.y+=pt.y;
> }
> }
>
> instead of desugaring to:
>
> u=u+v;  // which would cause the creation of an object and
> // leave the other to be collected
>
> For all I know, += might be doing such anyway in some engines, but for
> my stuff which is a lot of 3D math that could be a performance killer.
> It would be nice to be able to just add points and such, as long as the
> overhead is negligible.
>
> [>] Brian
>
> On 5/10/2016 10:52 AM, Isiah Meadows wrote:
> > I would prefer syntax + internal slots, since you'll know at creation
> > time whether the object has overloaded operators. It's much simpler for
> > the engine to figure out, and it's more performant because you only need
> > to check one thing instead of worrying about inheritance, own
> > properties, etc.
> >
> > Also, it would be IMHO easier to read than a symbol (the computed
> > property syntax is ugly IMO). Using a different concept than symbols
> > would also fit better with value types whenever any of those proposals
> > make it into the language (either the struct or special syntax).
> >
> >
> > On Tue, May 10, 2016, 04:03 G. Kay Lee
> >  > > wrote:
> >
> > Yes, I think exposing operators through well-known symbols is an
> > interesting idea worthy of more exploration because it's precisely
> > the purpose of well-known symbols to expose and allow manipulation
> > to previously inaccessible internal language behaviors.
> >
> > On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash
> > > wrote:
> >
> > > And remember that decorators are essentially just a syntax to
> > apply functions to objects/classes at design time, so what
> > you're proposing is essentially some new global function, which
> > is going against the current trend and effort to better
> > modularize/namespace all these utility functions/methods.
> >
> > That's a really good point.
> >
> > > It has been mentioned and discussed in numerous places over the
> > years, you can find more info on this with some casual googling.
> > For example:https://news.ycombinator.com/item?id=2983420
> >
> > Thanks for the link.  I played around with sweet.js a bit over
> > the weekend.  Using macros should work if we went with Python
> > style operator overloading.  Instead of defining methods like
> > _ADD_, _SUB_ etc. we could create some well-known symbols, maybe
> > Symbol.plus, Symbol.times, etc.
> >
> > ```
> > class Point {
> >   constructor(x, y) {
> > Object.assign(this, {x, y});
> >   }
> >
> >   [Symbol.add](other) {
> > return new Point(this.x + other.x, this.y + other.y);
> >   }
> > }
> >
> > const u = new Point(5, 10);
> > const v = new Point(1, -2);
> >
> > const w = u + v;  // desugars to u[Symbol.add](v)
> > console.log(w);   // { x: 6, y: 8 };
> > ```
> >
> > This would require default implementations to be defined on
> > Object.prototype for Symbol.plus, Symbol.times, etc.
> >
> >
> > On Sun, May 8, 2016 at 10:38 PM, G. Kay Lee
> >  > > wrote:
> >
> > > Why not? The standard defines well-known symbols. Maybe
> `@operator` could be a well known decorator (assuming decorators get
> approved).
> >
> > Well... you make something into the standard with proposals,
> > not why-nots, so in order to make that happen you need to
> > draft another proposal for well-known decorators. And
> > remember that decorators are essentially just a syntax to
> > apply functions to objects/classes at design time, so what
> > you're proposing is essentially some new global function,
> 

Re: Proposing a conditional assignment (or equals) operator

[Isiah Meadows]

Thought I'd mention this has been discussed before:

- https://esdiscuss.org/topic/existential-operator-null-propagation-operator
- https://esdiscuss.org/topic/the-existential-operator
-
https://esdiscuss.org/topic/optional-chaining-aka-existential-operator-null-propagation
- https://esdiscuss.org/topic/proposal-for-a-null-coalescing-operator
- https://esdiscuss.org/topic/operator-was-es6-doesn-t-need-opt-in

Currently, here's what I've seen emerge out of these discussions as the
most likely, each of them chainable:

1. `x ?? y` for `x != null ? x : y`
2. `x??y` or `x?.y` for `x != null ? x.y : undefined`

In #2, the operator works similarly for computed access, function calls,
etc., like in `f?.(x)` equivalent to `f != null ? f(x) : undefined`

On Tue, May 10, 2016, 08:50 Bruno Jouhier  wrote:

> `??=` is cleaner and avoids problems when the default is falsy but not
> undefined. But then we also need `??`.
> ___
> 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: operator overloading proposal

[Brian Barnes]

A note on this from somebody who's entire existence seems dedicated to 
stopping as much stuff as possible from getting GC'd, the example below:


>const u = new Point(5, 10);
>const v = new Point(1, -2);
>
>const w = u + v;  // desugars to u[Symbol.add](v)
>console.log(w);   // { x: 6, y: 8 };

Could += be a special case?  i.e.,

u+=v;

would call:

Class Point { ... other stuff ...
[whatever the syntax is](pt)
{
this.x+=pt.x;
this.y+=pt.y;
}
}

instead of desugaring to:

u=u+v;  // which would cause the creation of an object and
// leave the other to be collected

For all I know, += might be doing such anyway in some engines, but for 
my stuff which is a lot of 3D math that could be a performance killer. 
It would be nice to be able to just add points and such, as long as the 
overhead is negligible.


[>] Brian

On 5/10/2016 10:52 AM, Isiah Meadows wrote:

I would prefer syntax + internal slots, since you'll know at creation
time whether the object has overloaded operators. It's much simpler for
the engine to figure out, and it's more performant because you only need
to check one thing instead of worrying about inheritance, own
properties, etc.

Also, it would be IMHO easier to read than a symbol (the computed
property syntax is ugly IMO). Using a different concept than symbols
would also fit better with value types whenever any of those proposals
make it into the language (either the struct or special syntax).


On Tue, May 10, 2016, 04:03 G. Kay Lee
> wrote:

Yes, I think exposing operators through well-known symbols is an
interesting idea worthy of more exploration because it's precisely
the purpose of well-known symbols to expose and allow manipulation
to previously inaccessible internal language behaviors.

On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash
> wrote:

> And remember that decorators are essentially just a syntax to
apply functions to objects/classes at design time, so what
you're proposing is essentially some new global function, which
is going against the current trend and effort to better
modularize/namespace all these utility functions/methods.

That's a really good point.

> It has been mentioned and discussed in numerous places over the
years, you can find more info on this with some casual googling.
For example:https://news.ycombinator.com/item?id=2983420

Thanks for the link.  I played around with sweet.js a bit over
the weekend.  Using macros should work if we went with Python
style operator overloading.  Instead of defining methods like
_ADD_, _SUB_ etc. we could create some well-known symbols, maybe
Symbol.plus, Symbol.times, etc.

```
class Point {
  constructor(x, y) {
Object.assign(this, {x, y});
  }

  [Symbol.add](other) {
return new Point(this.x + other.x, this.y + other.y);
  }
}

const u = new Point(5, 10);
const v = new Point(1, -2);

const w = u + v;  // desugars to u[Symbol.add](v)
console.log(w);   // { x: 6, y: 8 };
```

This would require default implementations to be defined on
Object.prototype for Symbol.plus, Symbol.times, etc.


On Sun, May 8, 2016 at 10:38 PM, G. Kay Lee
> wrote:

> Why not? The standard defines well-known symbols. Maybe 
`@operator` could be a well known decorator (assuming decorators get approved).

Well... you make something into the standard with proposals,
not why-nots, so in order to make that happen you need to
draft another proposal for well-known decorators. And
remember that decorators are essentially just a syntax to
apply functions to objects/classes at design time, so what
you're proposing is essentially some new global function,
which is going against the current trend and effort to
better modularize/namespace all these utility
functions/methods. And maybe a new mechanism could be
drafted for these new well-known decorators, so that we can
hide these new functions somewhere... but by now I hope it's
becoming clear that it's introducing way too much new
surface area for the language in exchange for one small feature.

> I haven't seen any proposals for macros, could you post a link?

It has been mentioned and discussed in numerous places over
the years, you can find more info on this with some casual
googling. For example:
https://news.ycombinator.com/item?id=2983420

Re: operator overloading proposal

[Isiah Meadows]

I would prefer syntax + internal slots, since you'll know at creation time
whether the object has overloaded operators. It's much simpler for the
engine to figure out, and it's more performant because you only need to
check one thing instead of worrying about inheritance, own properties, etc.

Also, it would be IMHO easier to read than a symbol (the computed property
syntax is ugly IMO). Using a different concept than symbols would also fit
better with value types whenever any of those proposals make it into the
language (either the struct or special syntax).

On Tue, May 10, 2016, 04:03 G. Kay Lee <
balancetraveller+es-disc...@gmail.com> wrote:

> Yes, I think exposing operators through well-known symbols is an
> interesting idea worthy of more exploration because it's precisely the
> purpose of well-known symbols to expose and allow manipulation to
> previously inaccessible internal language behaviors.
>
> On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash 
> wrote:
>
>> > And remember that decorators are essentially just a syntax to apply
>> functions to objects/classes at design time, so what you're proposing is
>> essentially some new global function, which is going against the current
>> trend and effort to better modularize/namespace all these utility
>> functions/methods.
>>
>> That's a really good point.
>>
>> > It has been mentioned and discussed in numerous places over the years,
>> you can find more info on this with some casual googling. For example:
>> https://news.ycombinator.com/item?id=2983420
>>
>> Thanks for the link.  I played around with sweet.js a bit over the
>> weekend.  Using macros should work if we went with Python style operator
>> overloading.  Instead of defining methods like _ADD_, _SUB_ etc. we could
>> create some well-known symbols, maybe Symbol.plus, Symbol.times, etc.
>>
>> ```
>> class Point {
>>   constructor(x, y) {
>> Object.assign(this, {x, y});
>>   }
>>
>>   [Symbol.add](other) {
>> return new Point(this.x + other.x, this.y + other.y);
>>   }
>> }
>>
>> const u = new Point(5, 10);
>> const v = new Point(1, -2);
>>
>> const w = u + v;  // desugars to u[Symbol.add](v)
>> console.log(w);   // { x: 6, y: 8 };
>> ```
>>
>> This would require default implementations to be defined on
>> Object.prototype for Symbol.plus, Symbol.times, etc.
>>
>>
>> On Sun, May 8, 2016 at 10:38 PM, G. Kay Lee <
>> balancetraveller+es-disc...@gmail.com> wrote:
>>
>>> > Why not? The standard defines well-known symbols. Maybe `@operator`
>>> could be a well known decorator (assuming decorators get approved).
>>>
>>> Well... you make something into the standard with proposals, not
>>> why-nots, so in order to make that happen you need to draft another
>>> proposal for well-known decorators. And remember that decorators are
>>> essentially just a syntax to apply functions to objects/classes at design
>>> time, so what you're proposing is essentially some new global function,
>>> which is going against the current trend and effort to better
>>> modularize/namespace all these utility functions/methods. And maybe a new
>>> mechanism could be drafted for these new well-known decorators, so that we
>>> can hide these new functions somewhere... but by now I hope it's becoming
>>> clear that it's introducing way too much new surface area for the language
>>> in exchange for one small feature.
>>>
>>> > I haven't seen any proposals for macros, could you post a link?
>>>
>>> It has been mentioned and discussed in numerous places over the years,
>>> you can find more info on this with some casual googling. For example:
>>> https://news.ycombinator.com/item?id=2983420
>>>
>>>
>>>
>>> On Sun, May 8, 2016 at 2:51 PM, Kevin Barabash 
>>> wrote:
>>>
 I should update the demo code to show the `@operator` decorator in
 addition to `Function.defineOperator`.

 Initially I started out with just the `@operator` decorator, but that
 meant that each class would have to have knowledge of each of the classes
 it might want to interact with before hand.  Having a separate
 `defineOperator` function avoids this situation.

 It means that prototype style classes must be converted to the new
 class syntax before operator overloading could be used.  Lastly, there may
 be some cases where it makes sense to overload operators with existing 3rd
 party code or built-in classes, e.g. adding set operations to Set using
 operator overloading.

 > It's also apparent that the `@operator decorator` part of the
 proposal is an effort trying to address this issue, but it really is not
 the responsibility of the standard to try to define such a thing.

 Why not?  The standard defines well-known symbols.  Maybe `@operator`
 could be a well known decorator (assuming decorators get approved).

 Slide 15 from http://www.slideshare.net/BrendanEich/js-resp shows
 syntax for defining operators in 

Re: Proposing a conditional assignment (or equals) operator

[Bruno Jouhier]

`??=` is cleaner and avoids problems when the default is falsy but not
undefined. But then we also need `??`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is `undefined` garabage collectable?

[Andreas Rossberg]

Arrays are probably your best bet (but don't ever `delete` elements, or
change the size of your array!).

I don't understand what you mean by "placeholder". But FWIW, array keys
(i.e., small integers) are usually unboxed, i.e., not heap-allocated.

A general advise, though: don't be over-concerned with GC. There are a lot
of misconceptions about its performance. It is quite efficient in most
practical cases -- much more so than most attempts to work around it and
manage life-times manually.

On 9 May 2016 at 20:06, /#!/JoePea  wrote:

> Thanks Andreas, that's helpful to know. In general, is there some way to
> keep a list (adding removing things over time) while avoiding GC?
>
> For example, I thought I could place and remove items into a list (f.e.
> Set or Map, while having my own references to all the items and the list
> and outside of the list as well as to the list itself), but as you pointed
> out that still can have need for GC.
>
> I know you said
>
> > In general, there is very little you can do in JavaScript that does not
> potentially cause allocation and thus GC
>
> But, I would at least want to know that I minimized GC as much as
> possible. My first hunch (for my case) would be to make a linked list out
> of the items I need to have a "list" of, where each item's link (reference)
> to the next item is also one of the references that I already hold outside
> of the list?
>
> It seems that with Arrays (and Sets and Maps) that deleting an item from
> the list also deletes the placeholder that was used for that item (in the
> case of Array, the placeholders would be the numerical keys that are
> deleted when an item is popped for example), and I'm guessing (with my
> still expanding VM knowledge) that those placeholders are GCed separately
> from the thing that was referenced to by the placeholder (so even if the
> placeholder contained `null` there would still be GC). Is that a good guess?
>
> I'll be experimenting...
>
> On Mon, May 9, 2016 at 2:28 AM, Andreas Rossberg 
> wrote:
>
>> The `undefined` value is represented in exactly the same way as `true`,
>> `false`, and `null` in V8. They're so called "oddballs" internally, global
>> values that are neither allocated nor freed.
>>
>> Either way, the key/values of a (regular) map do not keep anything alive
>> about the map. Adding or removing entries from a set or map can of course
>> cause allocation/deallocation, regardless of the keys/values themselves.
>> (Similarly if you are using regular objects as maps, btw.)
>>
>> There are also lots of other things that cause allocation/deallocation
>> under the hood of a JavaScript engine, e.g. compilation, optimisation,
>> deoptimisation, etc. Some of that predominantly happens at start-up. If you
>> want to reduce random noise from your experiments, try to warm up the code
>> first. But even then, don't read too much into micro-benchmarks -- JS VMs
>> are far too complicated, dynamic, and heuristics-based to draw useful
>> conclusions from tiny tests (that's e.g. why JSPerf tests are often
>> bollocks).
>>
>> In general, there is very little you can do in JavaScript that does not
>> potentially cause allocation and thus GC. Certainly nothing involving
>> dynamic data structures.
>>
>> /Andreas
>>
>>
>> On 5 May 2016 at 07:48, /#!/JoePea  wrote:
>>
>>> > The only v8 shell I have lying around is too old (3.14.5.10) to have
>>> Set, so I can't tell you what it would do.
>>>
>>> On my first attempt, I noticed 8 Major GCs:
>>> https://cloud.githubusercontent.com/assets/297678/15036715/f41ea4d4-1247-11e6-8823-f153c3c1b7bb.png
>>>
>>> On second attempt, no Major GCs:
>>> https://cloud.githubusercontent.com/assets/297678/15036788/c066483a-1248-11e6-970b-3f9d20710bbc.png
>>>
>>> I wonder why. I'm in Chrome 50.
>>>
>>> So, the second attempt looks good. I'm not sure why the first is so
>>> different. I tried it a few times, but I only got that Major GC zig-zag the
>>> first time.
>>>
>>> Thanks for pointing out Set!
>>>
>>> On Wed, May 4, 2016 at 7:30 PM, Boris Zbarsky  wrote:
>>>
 On 5/4/16 5:03 PM, Steve Fink wrote:

> The only v8 shell I have lying around is too old (3.14.5.10) to have
> Set, so I can't tell you what it would do.
>

 I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and
 it does 1163 minor ("Scavenge") GCs on your testcase.  It also does 1163
 minor GCs if I take out the add() calls.  It does none if I remove the
 clear() calls, no matter whether the add() calls are there or not.

 -Boris
 ___
 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: Proposing a conditional assignment (or equals) operator

[Bruno Jouhier]

A big +1.

A quick grep on our code base shows 3000+ occurrences of the x = x || y
idiom in 700+ files. This proposal would make this code more compact and
more efficient, as it avoids redundant assignments.

The x = x && y idiom is a lot less common: 150 occurrences only, and is
usually associated with questionable reuse of a polymorphic variable to
walk a chain. But it would seem logical to extend the proposal to &&=.

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

Re: Proposing a conditional assignment (or equals) operator

[Claude Pache]

> Le 10 mai 2016 à 09:44, G. Kay Lee  a 
> écrit :
> 
> 
> Can't remember any instance where I've written something like `x = x || {}` 
> after the introduction of Default Parameters in ES6, so I don't see any 
> chance for me writing something like `x ||= {}` even if this thing somehow 
> makes its way in.

Some people do have use cases despite default arguments, see e.g. 
https://esdiscuss.org/topic/is-much-needed#content-4 


> 
> The thing is, it's far more common to encounter codes like `x = y || {}`, and 
> then a new Default Operator would make sense due to the issue with falsy 
> values. So I'd throw my support behind an authentic Default Operator proposal 
> like `x = y ?? {}` 
> (http://wiki.ecmascript.org/doku.php?id=strawman:default_operator 
> ). But 
> definitely not `||=`.
> 

Agree. I wonder why people keep to reclaim a `||=` operator (with semantics 
inspired from binary `||`), when their use cases generally show that `??=` is 
more appropriate (with approximate semantics of: `if (a === undefined) a = b;`).

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

Re: operator overloading proposal

[G. Kay Lee]

Yes, I think exposing operators through well-known symbols is an
interesting idea worthy of more exploration because it's precisely the
purpose of well-known symbols to expose and allow manipulation to
previously inaccessible internal language behaviors.

On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash 
wrote:

> > And remember that decorators are essentially just a syntax to apply
> functions to objects/classes at design time, so what you're proposing is
> essentially some new global function, which is going against the current
> trend and effort to better modularize/namespace all these utility
> functions/methods.
>
> That's a really good point.
>
> > It has been mentioned and discussed in numerous places over the years,
> you can find more info on this with some casual googling. For example:
> https://news.ycombinator.com/item?id=2983420
>
> Thanks for the link.  I played around with sweet.js a bit over the
> weekend.  Using macros should work if we went with Python style operator
> overloading.  Instead of defining methods like _ADD_, _SUB_ etc. we could
> create some well-known symbols, maybe Symbol.plus, Symbol.times, etc.
>
> ```
> class Point {
>   constructor(x, y) {
> Object.assign(this, {x, y});
>   }
>
>   [Symbol.add](other) {
> return new Point(this.x + other.x, this.y + other.y);
>   }
> }
>
> const u = new Point(5, 10);
> const v = new Point(1, -2);
>
> const w = u + v;  // desugars to u[Symbol.add](v)
> console.log(w);   // { x: 6, y: 8 };
> ```
>
> This would require default implementations to be defined on
> Object.prototype for Symbol.plus, Symbol.times, etc.
>
>
> On Sun, May 8, 2016 at 10:38 PM, G. Kay Lee <
> balancetraveller+es-disc...@gmail.com> wrote:
>
>> > Why not? The standard defines well-known symbols. Maybe `@operator`
>> could be a well known decorator (assuming decorators get approved).
>>
>> Well... you make something into the standard with proposals, not
>> why-nots, so in order to make that happen you need to draft another
>> proposal for well-known decorators. And remember that decorators are
>> essentially just a syntax to apply functions to objects/classes at design
>> time, so what you're proposing is essentially some new global function,
>> which is going against the current trend and effort to better
>> modularize/namespace all these utility functions/methods. And maybe a new
>> mechanism could be drafted for these new well-known decorators, so that we
>> can hide these new functions somewhere... but by now I hope it's becoming
>> clear that it's introducing way too much new surface area for the language
>> in exchange for one small feature.
>>
>> > I haven't seen any proposals for macros, could you post a link?
>>
>> It has been mentioned and discussed in numerous places over the years,
>> you can find more info on this with some casual googling. For example:
>> https://news.ycombinator.com/item?id=2983420
>>
>>
>>
>> On Sun, May 8, 2016 at 2:51 PM, Kevin Barabash 
>> wrote:
>>
>>> I should update the demo code to show the `@operator` decorator in
>>> addition to `Function.defineOperator`.
>>>
>>> Initially I started out with just the `@operator` decorator, but that
>>> meant that each class would have to have knowledge of each of the classes
>>> it might want to interact with before hand.  Having a separate
>>> `defineOperator` function avoids this situation.
>>>
>>> It means that prototype style classes must be converted to the new class
>>> syntax before operator overloading could be used.  Lastly, there may be
>>> some cases where it makes sense to overload operators with existing 3rd
>>> party code or built-in classes, e.g. adding set operations to Set using
>>> operator overloading.
>>>
>>> > It's also apparent that the `@operator decorator` part of the
>>> proposal is an effort trying to address this issue, but it really is not
>>> the responsibility of the standard to try to define such a thing.
>>>
>>> Why not?  The standard defines well-known symbols.  Maybe `@operator`
>>> could be a well known decorator (assuming decorators get approved).
>>>
>>> Slide 15 from http://www.slideshare.net/BrendanEich/js-resp shows
>>> syntax for defining operators in value types which could be adapted as
>>> follows for regular classes:
>>>
>>> ```
>>> class Point {
>>>constructor(x, y) {
>>>this.x = +x;
>>>this.y = +y;
>>>}
>>>Point + Number (a, b) {
>>>return new Point(a.x + b, a.y + b);
>>>}
>>>Number + Point (a, b) {
>>>return new Point(a + b.x, a + b.y);
>>>}
>>>Point + Point (a, b) {
>>>return new Point(a.x + b.x, a.y + b.y);
>>>}
>>> }
>>> ```
>>>
>>> Having to define `+` twice for `Point + Number` and `Number + Point`
>>> seems like busy work, but maybe it's better to be explicit.  What are you
>>> thoughts about this syntax?
>>>
>>> > Another thing is that, IMHO, currently there are too much
>>> quirks/conventions in the proposal that 

Re: Proposing a conditional assignment (or equals) operator

[G. Kay Lee]

Not convinced. Failed to see any reason why this proposal could force its
way through this time after repeatedly being raised from dead only to be
put down time after time. I don't see any new, convincing rationales here.
On the other hand I can give out two reasons on why we don't need this
thing fair quickly:

1.
```
// This is so unambiguous everyone who knows programming can read this
const config = config || {};

// No true for this one as pointer out in previous discussions as well as
the Ruby article you mentioned
const config ||= {};
```

2.
Honestly? Why are codes like this being written?

```
var config = {flag: true};
config = config || {};

...

function f (config) {
  const config = config || {};
}
```

I always write things like this:

```
var config = {flag: true} || {};

...

function f (config = {}) {
  ...
}
```

Can't remember any instance where I've written something like `x = x || {}`
after the introduction of Default Parameters in ES6, so I don't see any
chance for me writing something like `x ||= {}` even if this thing somehow
makes its way in.

The thing is, it's far more common to encounter codes like `x = y || {}`,
and then a new Default Operator would make sense due to the issue with
falsy values. So I'd throw my support behind an authentic Default Operator
proposal like `x = y ?? {}` (
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator). But
definitely not `||=`.


On Tue, May 10, 2016 at 12:10 PM, Doug Wade 
wrote:

> I see this has been discussed on this list a number of times before -- I
> found this thread
> ,
> and reviewed the linked discussions and previous strawmen (I hope that link
> is enough to establish context and why the operator is useful; I can
> provide more insight if it would be helpful).  I understand the problem is
> fraught and thorny, but I believe the language would greatly benefit from
> it.
>
> I spent some time reflecting on what I think would be expected of such an
> operator (most notably that it be as close to the other assignment
> operators +=, -=  and the || operator as I could manage, and that it
> match the ||= operator in Ruby
> 
>  fairly
> closely) and wrote up a quick reference implementation (-ish? see babylon
> (parser)
>  and babel
> (compiler)
> )
> and an set of test cases
>  to match what
> I think expresses my thoughts on what I personally would expect from such
> an operator more eloquently than I think I could in words (please don't
> think me presumptuous; I thought it easier to write out my thoughts in code
> than English, not that the debate would be so simple that my implementation
> would be rubber stamped).
>
> I have reviewed the process documentation
>  and the contributing guide
> , and I
> believe I am seeking a TC39 champion to make this a stage 0 strawman
> proposal, though I will admit that from my review of the archives
>  there is likely to be a lot of discussion before
> we reach that point.  Please advise me as to what more I can do to get this
> included in the ES standard.
>
> All the best,
> Doug Wade
>
> ___
> 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