There is no intrinsic reason why we needed to mandate that class constructors
should throw when called. We even provided a simple and straight forward way
(new.target===undefined) that a ES constructor body can use to determine
whether it was called or new’ed.
I think we should just
On Sun, Mar 29, 2015 at 10:49 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 29, 2015, at 11:51 PM, Caitlin Potter caitpotte...@gmail.com
wrote:
...
Reflect.isConstructor(fn) - true if Class constructor, generator, or
legacy (and non-builtin) function syntactic form
It doesn’t seem that big of a deal, but one risk is: people mistaking a class
for a constructor, trying to subclass it as if it were a constructor and things
failing silently.
On 30 Mar 2015, at 07:49, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 29, 2015, at 11:51 PM, Caitlin
It doesn’t seem that big of a deal, but one risk is: people mistaking a
class for a constructor, trying to subclass it as if it were a constructor
and things failing silently.
Can you give an example of what you mean?
```js
class MySuperClass {}
// This function assumes that MySuperClass
```js
class MySuperClass {}
// This function assumes that MySuperClass is an ES5 constructor function
function MySubConstructor(foo) {
MySuperClass.call(this);
this.foo = foo;
}
MySubConstructor.prototype = Object.create(MySuperClass.prototype);
On Mar 30, 2015, at 8:09 AM, Yehuda Katz wyc...@gmail.com wrote:
...
I don't think this is an accurate representation of the discussion we had.
It’s my characterization of the situation and reflects my position. I agreed to
disabling calling class constructors via a throw in order to get
On Mar 30, 2015, at 10:12 AM, Axel Rauschmayer a...@rauschma.de wrote:
It doesn’t seem that big of a deal, but one risk is: people mistaking a
class for a constructor, trying to subclass it as if it were a constructor
and things failing silently.
Can you give an example of what you
On Mar 30, 2015 10:54 AM, Axel Rauschmayer a...@rauschma.de wrote:
```js
class MySuperClass {}
// This function assumes that MySuperClass is an ES5 constructor function
function MySubConstructor(foo) {
MySuperClass.call(this);
this.foo = foo;
}
MySubConstructor.prototype
On Mar 30, 2015, at 8:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
It doesn’t seem that big of a deal, but one risk is: people mistaking a class
for a constructor, trying to subclass it as if it were a constructor and
things failing silently.
Can you give an example of what you mean?
Don’t the different assumptions as to where the instance is allocated ever
clash here? What if `MySuperClass` were:
```js
class MySuperClass extends Error {
}
```
MySubClass preallocates when invoked via new. Just like ES5. So,
```MySuperClass.call(this)``` is same as ES5.
On Mar 30, 2015, at 1:49 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
There is no intrinsic reason why we needed to mandate that class constructors
should throw when called. We even provided a simple and straight forward way
(new.target===undefined) that a ES constructor body can use to
Thanks Caitlin for actually putting this onto github! I wasn't aware of
that process when I posted about this to the mailinglist. Asking again from
last time: Should we have Type == Object check like Reflect.isExtensible?
-Tom
On Sun, Mar 29, 2015 at 11:51 PM, Caitlin Potter
Le 30 mars 2015 à 10:46, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
On Mar 30, 2015, at 10:12 AM, Axel Rauschmayer a...@rauschma.de wrote:
It doesn’t seem that big of a deal, but one risk is: people mistaking a
class for a constructor, trying to subclass it as if it were a
On Mar 30, 2015, at 10:12 AM, Axel Rauschmayer axel at rauschma.de
wrote:
It doesn’t seem that big of a deal, but one risk is: people mistaking
a class for a constructor, trying to subclass it as if it were a
constructor and things failing silently.
Can you give an example of what you mean?
On Mon, Mar 30, 2015 at 5:36 AM, Caitlin Potter caitpotte...@gmail.com
wrote:
On Mar 30, 2015, at 1:49 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
There is no intrinsic reason why we needed to mandate that class
constructors should throw when called. We even provided a simple and
I don’t think [Symbol.call] is a very good mechanism. A new syntactic form
would make more sense.
It doesn’t seem right that you should have to introduce an observable prototype
property just to get [[Call]] behavior. (Or a constructor property, if you
change the syntax to `static
But in either case, these (IsCallable / IsConstructor) are pretty basic
qualities of objects that a Reflection* api ought to be able to read into,
imho.
What Allen is saying is that the implementation of throw if constructor
doesn't work by not implementing [[Call]], but rather by implementing
Great to get the ball rolling. Here's some issues I'd bring up at the meeting,
so we can get a head start:
- As discussed recently in
https://esdiscuss.org/topic/reflect-getownpropertysymbols, right now Reflect
only holds counterparts to the proxy traps. I think this is kind of a nice
Cc: es-discuss@mozilla.org
Subject: Re: Determine if a value is Callable/Constructible
But in either case, these (IsCallable / IsConstructor) are pretty basic
qualities of objects that a Reflection* api ought to be able to read into,
imho.
What Allen is saying is that the implementation
It doesn’t seem right that you should have to introduce an observable
prototype property just to get [[Call]] behavior. (Or a constructor
property, if you change the syntax to `static [Symbol.call]() { … }`.)
And it raises the question of what happens when I add a [Symbol.call]
property to
Yehuda Katz
(ph) 718.877.1325
On Mon, Mar 30, 2015 at 8:09 AM, Domenic Denicola d...@domenic.me wrote:
I don’t think [Symbol.call] is a very good mechanism. A new syntactic form
would make more sense.
It doesn’t seem right that you should have to introduce an observable
prototype property
return function, which would be ... O_o.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Caitlin Potter
Sent: Monday, March 30, 2015 11:25
To: Yehuda Katz
Cc: es-discuss@mozilla.org
Subject: Re: Determine if a value is Callable/Constructible
I like the idea of a special syntactic form a lot. One of the nice things
about `constructor` is that it's easy to explain you [[Construct]] with
the constructor. We can't use `call` similarly any more, but I totally
agree something like it would be pretty nice.
Unfortunately, we can't use
On 3/30/15 1:33 PM, Axel Rauschmayer wrote:
As in “makes sense to call”. In the past, `typeof x === 'function'” was
an adequate test for checking whether it makes sense to call `x`.
Except for all the DOM constructors, right?
-Boris
___
es-discuss
On Mar 30, 2015, at 12:20 PM, Domenic Denicola d...@domenic.me wrote:
Why do you say they're not callable?
Is this function callable?
function f() {
throw new TypeError(“f immediately throws);
}
I think there’s a distinction here.
`function f() {}` might throw when called, but
It could still be identified as a “function” for compat with ES5, but the
behaviour is different from any other sort of function, it should be
identifiable as different.
Right, but again, I don't think the behavior is any different from `function
f() { throw new TypeError(); }`, so whatever
The distinction you're really pointing to here is the distinction between
user-generated throwing functions and runtime-generated ones. Both are called.
User-generated ones you could edit the source code of and insert a `called =
true` line first, whereas runtime-generated ones you could not.
That distinction means that you can’t “really” [[Call]] a constructor,
it’s just that the reason is slightly different from trying to [[Call]] an
Array instance (or something)
Another way to look at the situation is that, by default, calling a class
constructor will throw an error. That
Unfortunately, we can't use a magic method name. Just to throw out a couple
of other ideas though:
Contextual keyword after constructor:
class C {
constructor() { /* new me */ }
constructor call() { /* call me */ }
}
This one looks like the most readable — I would make a
In some way, that would even be correct – depending on what you expect a
function to be: something callable or something constructible. Alas, there
is currently no simple way to distinguish “callable” and “constructible”.
Why do you say they're not callable?
As in “makes sense to call”.
On Mar 30, 2015, at 1:44 PM, Domenic Denicola d...@domenic.me wrote:
From: Axel Rauschmayer [mailto:a...@rauschma.de]
As in “makes sense to call”. In the past, `typeof x === 'function'” was an
adequate test for checking whether it makes sense to call `x`.
I tried to explain explicitly why I
I think we’re on the same page that the runtime is the one doing the throwing,
but that doesn’t really matter. The point is, if you can’t actually invoke the
authored code, you can’t really call the authored code “call-able”. To the VM,
the difference doesn’t matter a whole lot, but to human
From: Axel Rauschmayer [mailto:a...@rauschma.de]
In some way, that would even be correct – depending on what you expect a
function to be: something callable or something constructible. Alas, there is
currently no simple way to distinguish “callable” and “constructible”.
Why do you say
I personally think it's better to have **harmony** between ES5 and ES6
classes and not incompatibility.
The web and the like are currently littered with applications that use
[[call]] as a sub classing technique and now all these apps will be
give a harsh choice, either disregard using ES6 class
From: Kevin Smith [mailto:zenpars...@gmail.com]
I'd imagine that you'd re-spec [[Call]] for class constructors to basically
do `this[Symbol.call](...args)` instead of just throw. It would therefore
only have an effect within class constructors. Is that still weird?
At least it's
On Mon, Mar 30, 2015 at 8:54 AM, Domenic Denicola d...@domenic.me wrote:
From: Kevin Smith [mailto:zenpars...@gmail.com]
I'd imagine that you'd re-spec [[Call]] for class constructors to
basically do `this[Symbol.call](...args)` instead of just throw. It would
therefore only have an effect
If you made them non-callable by not implementing [[Call]], then typeof would
no longer return function, which would be ... O_o.
In some way, that would even be correct – depending on what you expect a
function to be: something callable or something constructible. Alas, there is
currently no
Caitlin Potter wrote:
Well just to get the ball rolling, I’ve put together a markdown doc
for this
https://github.com/caitp/TC39-Proposals/blob/master/tc39-reflect-isconstructor-iscallable.md
It’s such a minor item that I’m not sure how much to add to it, so
maybe someone else will have a
Last thread:
https://esdiscuss.org/topic/add-reflect-isconstructor-and-reflect-iscallable.
Died off again.
There's no issue with ES7 vs. ES6 without a spec, and having a draft
spec at the right stage (1 for flagged implementation?) is the thing.
Who will do it?
/be
Caitlin Potter wrote:
On Mar 29, 2015, at 11:51 PM, Caitlin Potter caitpotte...@gmail.com wrote:
...
Reflect.isConstructor(fn) - true if Class constructor, generator, or legacy
(and non-builtin) function syntactic form
Reflect.isCallable(fn) - true for pretty much any function, except for class
Well just to get the ball rolling, I’ve put together a markdown doc for this
https://github.com/caitp/TC39-Proposals/blob/master/tc39-reflect-isconstructor-iscallable.md
https://github.com/caitp/TC39-Proposals/blob/master/tc39-reflect-isconstructor-iscallable.md
It’s such a minor item that I’m
41 matches
Mail list logo
