iom I propose that we have a self
> referential version of it.
>
> Idiom:
> ```js
> myVar = myVar || "default" ;
> ```
>
> New Operator:
> ```js
> myVar ||= "default" ;
> ```
>
> Sebastian Malton
sign
proposed one is in charge
all the time.
4) I'm reluctant to put additional property probes/access in the fast
path of the 'new' operator. Object instantiation should be fast and
every extra property access or invocation costs something. Maybe they
can be optimized away, but maybe not...
I
and
nonconfigurable. So it cannot be changed, thus in no way legacy
[[Construct]] can be triggered and the newly proposed one is in charge
all the time.
4) I'm reluctant to put additional property probes/access in the fast
path of the 'new' operator. Object instantiation should be fast and
every
and
property accesses. I'd prefer not to lose that equivalence.
4) I'm reluctant to put additional property probes/access in the fast path of
the 'new' operator. Object instantiation should be fast and every extra
property access or invocation costs something. Maybe they can be optimized
away
Hello!
PROBLEM
In the present state of the spec, there is little inconsistency between
behaviour of new and super.
What these operation roughly do is:
new Foo(...args) is
Foo.call(Foo[@@create](), ...args)
super(...args) inside constructor is
Until ES.next, I’ve stuck to the simple rule: Always use `new` when you want to
create an instance. That avoids confusion when it comes to functions such as
String and Boolean: I like using them to coerce values.
Given that value object constructors such as uint64 are currently invoked
without
Axel Rauschmayer wrote:
Until ES.next, I’ve stuck to the simple rule: Always use `new` when
you want to create an instance. That avoids confusion when it comes to
functions such as String and Boolean: I like using them to coerce values.
User-defined constructors are often coded so that users
how to
keep JavaScript easy to teach. And with value object constructors we now have
three ways of creating instances (new Foo(...), Foo(...), foo(...)). If we want
to reduce the number of ways, there are two possibilities: (1) Advocate that
people use the `new` operator less. (2) Write uint64
Rauschmayer
Sent: Sunday, May 13, 2012 9:53 PM
To: Brendan Eich
Cc: es-discuss
Subject: Re: The new operator
Axel Rauschmayer wrote:
Until ES.next, I’ve stuck to the simple rule: Always use `new` when you
want to create an instance. That avoids confusion when it comes to functions
such as String
not be usable as WeakMap keys.)
If we want to reduce the number of ways, there are two possibilities:
(1) Advocate that people use the `new` operator less.
One size does not fit all, in practice and even in theory.
(2) Write uint64(123) as new UInt64(123) or as UInt64(123).
There are no such UInt64, etc
Brendan Eich wrote:
Again, nothing is new about value object constructors. Most
constructors can be called as functions (not via new) to construct.
Emphasis on constructors here. The novelty with value objects is not
in constructors callable without 'new', but in what I went on to write:
Finally, and Axel used ES.next clearly but I used ES6 so I'm clarifying
my own post: value objects are not in ES6.
Value objects are being prototyped in order to implementor- and
user-test, so they're on the Harmony agenda as a strawman proposal. For
SpiderMonkey, I will avoid exposing them
return pointers to
JS space, you find that, at some point, you need to cast. We decided to
arrange our ByteThing constructors so that they create *new* ByteThings
when invoked with the new operator, and otherwise treat their argument sort
of like a coercion source. We call this ByteThing casting
Value objects are new under the sun. They are not the same as the primitive
AKA value types built into JS. They are typeof-type object but equal by
value not reference (under the hood there's a pointer-compare fast path, of
course). They are frozen so you can't decorate them with expandos
Hope this is clear. To your point, and as Francois posted, teaching people to
leave out 'new' is not going to work in various cases. Better to teach
subsets starting with ES5 strict or smaller, and build up from there
(including XHR at some point). A fair amount (not all) of ES6 should be
Finally, and Axel used ES.next clearly but I used ES6 so I'm clarifying my
own post: value objects are not in ES6.
Value objects are being prototyped in order to implementor- and user-test, so
they're on the Harmony agenda as a strawman proposal. For SpiderMonkey, I
will avoid exposing
Axel Rauschmayer wrote:
Value objects are new under the sun. They are not the same as the
primitive AKA value types built into JS. They are typeof-type
object but equal by value not reference (under the hood there's a
pointer-compare fast path, of course). They are frozen so you can't
17 matches
Mail list logo
