2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Anotherconcern I have with @@new, it that it exposes two extension points,
@@new and @@create, on very constructor. I'm afraid that it wouldn't be
very clear to most ES programmers when you should over-ride one or the
other.
On Jun 15, 2014, at 11:45 PM, Tom Van Cutsem wrote:
2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Anotherconcern I have with @@new, it that it exposes two extension points,
@@new and @@create, on very constructor. I'm afraid that it wouldn't be very
clear to most ES
On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Interesting. It'd be nice if we could further simplify the Proxy/Reflect
API. Given the local nature of these changes, we might still include it in
ES6 if we achieve quick consensus.
I'm mostly interested in getting rid
On Jun 16, 2014, at 3:02 PM, Jason Orendorff wrote:
On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Interesting. It'd be nice if we could further simplify the Proxy/Reflect
API. Given the local nature of these changes, we might still include it in
ES6 if we achieve
On Mon, Jun 16, 2014 at 5:39 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Perhaps you could fill out what you actually mean by @@new and how it would
work for regular functions, class declarations, and subclasses of both
regular classes and the legacy built-ins.
Yes, that's a very good
Interesting. It'd be nice if we could further simplify the Proxy/Reflect
API. Given the local nature of these changes, we might still include it in
ES6 if we achieve quick consensus.
As Allen mentioned, this came up a number of times in TC39 meetings and I
believe the fear for exotic objects that
On 13 June 2014 12:33, Tom Van Cutsem tomvc...@gmail.com wrote:
One important detail:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
new C(...args) = C.apply(C[Symbol.create](), args)
I prefer Jason's transformation for the following reason: imagine a
On 6/13/14, 6:33 AM, Tom Van Cutsem wrote:
As Allen mentioned, this came up a number of times in TC39 meetings and
I believe the fear for exotic objects that require control over
[[Construct]] was the biggest show-stopper. If more knowledgeable people
like Boris can vouch for the fact that this
On Fri, Jun 13, 2014 at 6:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
new C(...args) = C.apply(C[Symbol.create](), args)
Consider also the way the spec could read. For example, for the
'Error' object,
On Jun 13, 2014, at 8:05 AM, C. Scott Ananian wrote:
On Fri, Jun 13, 2014 at 6:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
new C(...args) = C.apply(C[Symbol.create](), args)
Consider also the way the spec
On 6/13/14, 1:21 PM, Allen Wirfs-Brock wrote:
It isn't clear if there are really any use cases that could be supported by
@@new that couldn't also be support by carefully crafting a @@create and
companion constructor function.
I agree. I was assuming in my mail trying to make sure I
On Jun 13, 2014, at 7:51 AM, Boris Zbarsky wrote:
On 6/13/14, 6:33 AM, Tom Van Cutsem wrote:
As Allen mentioned, this came up a number of times in TC39 meetings and
I believe the fear for exotic objects that require control over
[[Construct]] was the biggest show-stopper. If more
On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
Unless, I misunderstand I don't think Jason is proposing eliminating @@create.
I had assumed he was... I'm not sure I see the point if we're not doing
that.
The object you return is an instance of the superclass and not of the subclass.
Ah,
On Jun 13, 2014, at 11:02 AM, Boris Zbarsky wrote:
On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
The object you return is an instance of the superclass and not of the
subclass.
Ah, right.
So just to make sure, now that I think about it: in the @@create setup, where
is the prototype
On Fri, Jun 13, 2014 at 8:21 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 13, 2014, at 8:05 AM, C. Scott Ananian wrote:
On Fri, Jun 13, 2014 at 6:33 AM, Tom Van Cutsem tomvc...@gmail.com
wrote:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
One question about @@create though... What would this do:
function Foo () {}
Foo.prototype[Symbol.create] = null;
// ???
// Maybe error out, like currently host objects without [[Construct]]:
// TypeError: Foo is not a constructor.
new Foo();
- Jussi
```javascript
function Foo(){}
On Jun 13, 2014, at 12:07 PM, Jussi Kalliokoski wrote:
function Foo () {}
Foo.prototype[Symbol.create] = null;
@@create methods are normally defined as methods of the constructor function
rather than as an instance method on the prototype. So the above should be:
Foo[Symbol.create] =
On Fri Jun 13 2014 at 3:41:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 13, 2014, at 12:07 PM, Jussi Kalliokoski wrote:
function Foo () {}
Foo.prototype[Symbol.create] = null;
@@create methods are normally defined as methods of the constructor
function rather than
On Jun 13, 2014, at 1:02 PM, Erik Arvidsson wrote:
On Fri Jun 13 2014 at 3:41:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Hold on. We covered this in one of the face to face meetings and I was of the
impression it was decided that we should not have a fallback but instead
On 6/13/14, 2:20 PM, Allen Wirfs-Brock wrote:
The default @@create is approximately:
Function.prototype[Symbol.create] = function(I) {
return Object.create(this.prototype)
}
Ah, I see. So the point is in normal use @@create is passed the right
prototype to start with implicitly, via
On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we
On Jun 12, 2014, at 5:36 AM, Jason Orendorff wrote:
On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5);
.
From: Allen Wirfs-Brock al...@wirfs-brock.com
Sent: Thursday, June 12, 2014 10:59
To: Jason Orendorff
Cc: Domenic Denicola; EcmaScript
Subject: Re: IsConstructor
On Jun 12, 2014, at 5:36 AM, Jason Orendorff wrote:
On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.com
From: Allen Wirfs-Brock al...@wirfs-brock.com
Sent: Thursday, June 12, 2014 10:59
To: Jason Orendorff
Cc: Domenic Denicola; EcmaScript
Subject: Re: IsConstructor
On Jun 12, 2014, at 5:36 AM, Jason Orendorff wrote:
On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
al
I'd be most interested in seeing if we can remove IsConstructor entirely (except
for uses where it's just a guard, implementing the semantics of `new` via
IsConstructor - [[Construct]] or throw).
It seems like there's at least some movement toward removing it from `Array.of`
and `Array.from`.
On Jun 12, 2014, at 8:30 AM, Erik Arvidsson wrote:
Why can't we blindly call `this[[Construct]]`? It will throw for all of the
above cases which is pretty much what one would expect.
I already said I'd be fine with that. Personally I think the practice of
high-jacking methods and turning
On Thu Jun 12 2014 at 11:38:22 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
It when we start trying to give a function both this-dependent and
this-independent functional behavior that we get into the weeds.
Yes. Lets not do that :-)
___
On Jun 12, 2014, at 8:33 AM, André Bargull wrote:
I'd be most interested in seeing if we can remove IsConstructor entirely
(except for uses where it's just a guard, implementing the semantics of
`new` via IsConstructor - [[Construct]] or throw).
It seems like there's at least some
On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I'd be most interested in seeing if we can remove IsConstructor entirely
(except for uses where it's just a guard, implementing the semantics of `new`
via IsConstructor - [[Construct]] or throw).
It seems
On Thu, Jun 12, 2014 at 1:30 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
I *really* wish we just had an @@new for this, such that
new C(...args)
is just shorthand for
C[Symbol.new](...args)
and the construct trap could be removed from proxies altogether. :-|
I forgot to add:
On Thu, Jun 12, 2014 at 2:30 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
I *really* wish we just had an @@new for this, such that
new C(...args)
is just shorthand for
C[Symbol.new](...args)
and the construct trap could be removed from proxies altogether. :-|
+1.
On Jun 12, 2014, at 11:30 AM, Jason Orendorff wrote:
On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I'd be most interested in seeing if we can remove IsConstructor entirely
(except for uses where it's just a guard, implementing the semantics of
`new`
On 6/12/14, 3:21 PM, Allen Wirfs-Brock wrote:
simply not knowing whether all of the DOM [[Construct]] semantics could be
successfully replaced replaced using only @@create methods and constructor
bodies.
WebIDL currently doesn't use a custom [[Construct]] at all. It uses a
custom [[Call]]
On Jun 12, 2014, at 12:25 PM, Boris Zbarsky wrote:
On 6/12/14, 3:21 PM, Allen Wirfs-Brock wrote:
simply not knowing whether all of the DOM [[Construct]] semantics could be
successfully replaced replaced using only @@create methods and constructor
bodies.
WebIDL currently doesn't use a
On 6/12/14, 3:38 PM, Allen Wirfs-Brock wrote:
Is the custom [[Call]] only use to implement WebIDL overload/argument
processing semantics? Or do you perform object allocations within the [[Call].
Right now the [[Call]] allocates a new object of the right sort.
Have you looked at how such
On Thu, Jun 12, 2014 at 3:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
It's not obvious to me why we would need @@new in addition to @@create (which
is pretty much equivalent to saying it's not clear to me why we need
[[Construct]]). For the ordinary case, @@new would just be another
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so
the IsConstructor will always return true which is really not what you
want. If IsConstructor was changed to check for a .prototype instead
proxies would behave more inline with ordinary objects.
[[Construct]] is only
On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
A variety of places in the spec use the new IsConstructor abstract
operation. In ES5, this test (essentially, does the object implement the
[[Construct]] internal method) was restricted to the `new`
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
On Wed, Jun 11, 2014 at 10:58 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
This, as well as the other warning I posted.
Rick
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just
need to wait until Proxies are available everywhere! ;-)
On Wed, Jun 11, 2014 at
2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com:
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so
the IsConstructor will always return true which is really not what you
want. If IsConstructor was changed to check for a .prototype instead
proxies
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in a browser.
-Boris
___
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote:
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just need to
wait
On 6/11/2014 5:40 PM, Alexandre Morgaut wrote:
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote:
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be
On Jun 11, 2014, at 8:16 AM, Tom Van Cutsem wrote:
2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com:
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the
IsConstructor will always return true which is really not what you want. If
IsConstructor
On Jun 11, 2014, at 8:49 AM, André Bargull wrote:
From [1]:
```javascript
function IsConstructor(o) {
try {
new (new Proxy(o, {construct: () = ({})}));
return true;
} catch(e) {
return false;
}
}
```
This IsConstructor implementation does not trigger any side-effects
On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote:
A variety of places in the spec use the new IsConstructor abstract operation.
In ES5, this test (essentially, does the object implement the [[Construct]]
internal method) was restricted to the `new` operator. But in ES6, it is
used in
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we
On 11 June 2014 18:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Other than the Array.of and Array.from usages the other uses are all
necessary either functionally (you can't just try to construct by calling
[[Construct]], it requires an explicit guard) or to deal with special
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote:
A variety of places in the spec use the new IsConstructor abstract
operation. In ES5, this test (essentially, does the object implement the
[[Construct]]
Saving 12 bytes does not seem like an obvious end-programmer benefit
to me. It seems like unnecessary and premature optimization.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, 2014 13:31
To: Rick Waldron
Cc: EcmaScript
Subject: Re: IsConstructor
Saving 12 bytes does not seem like an obvious end-programmer benefit
to me. It seems like unnecessary and premature optimization.
--scott
___
es-discuss mailing list
es-discuss
2014-06-11 18:02 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Kind of boarder line. 6.1.7.2 says that the essential internal methods
are those listed in Table 5 (does not include [[Call]] and
[[Constructor]]). Also the definitions of [[Call]] and [[Construct]] in
9.5 each include a
I may still try to tighten up the language. I usually consider even one person
being uncertain about the meaning of some prose in the spec. to be an
indication that others will probably also be confused.
Allen
On Jun 11, 2014, at 10:49 AM, Tom Van Cutsem wrote:
2014-06-11 18:02 GMT+02:00
From: Allen Wirfs-Brock al...@wirfs-brock.com
There are a few uses of IsConstructor in some Array methods that deal with
subtle backwards compat issues that are a result of extending Array to be
subclassable. These are very unique cases and I don't think you should look
at them as
On Jun 11, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
There are a few uses of IsConstructor in some Array methods that deal with
subtle backwards compat issues that are a result of extending Array to be
subclassable. These are very unique
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
functions, when in reality they are definitely methods.
Yes, you're right.
What about Array subclasses? `from` and `of` are inherited
From: Rick Waldron waldron.r...@gmail.com
Or maybe that's not necessary? Is it preferable to just throw when someone
writes any of these:
I think it is indeed preferable, as would happen when using any other method
(`this`-dependent function) without a `this`.
(Note that `Array.isArray`
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Of course this can all be fixed with .bind() or a bind operator, but it
just seems unfortunate to throw out something that's not harming the spec in
favor something that might be problematic in end user
On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote:
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
functions, when in reality they are definitely methods.
Yes, you're right.
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Rick Waldron waldron.r...@gmail.com
Or maybe that's not necessary? Is it preferable to just throw when
someone writes any of these:
I think it is indeed preferable, as would happen when using any
On Wed, Jun 11, 2014 at 4:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote:
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
64 matches
Mail list logo
