> 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,
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
>
@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
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
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
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
-
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 };
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.
`??=` 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
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
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
> 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 ||=
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
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
14 matches
Mail list logo