I really like this proposal.
2014-06-17 21:32 GMT+02:00 C. Scott Ananian ecmascr...@cscott.net:
+1.
I think you could also remove the 'construct' handler in Proxy
(
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-construct-internal-method
step 4), as the @@new method can be
Your proposal is appealing but I haven't convinced myself it works. There are a
couple bits I haven't quite grokked.
The special `constructor` method in ClassDeclaration/ClassExpression syntax
would desugar to a static @@new method. This class:
class Point {
constructor(x = 0, y
On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
...
## Benefits
* As with Allen's proposal, we would drop [[Construct]] and the
`construct`
trap.
* @@create can be dropped entirely, but we retain the benefit to
implementers
that all Maps
On Tue, Jun 17, 2014 at 11:27 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote:
On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller erig...@gmail.com wrote:
I am happy with #b as well, though I prefer #c. I also agree with C.
Scott's
On 18 June 2014 09:40, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
## Benefits
* As with Allen's proposal, we would drop [[Construct]] and the
`construct`
trap.
* @@create can be dropped
On 6/18/14, 3:40 AM, Dmitry Soshnikov wrote:
Personally I think two traps are more intuitive and convenient (and are
present in many other languages: C++, Ruby, etc)
C++ has the sorts of restrictions on calling the superclass constructor
(have to do it up front, can't skip doing it) that the
From: Jason Orendorffmailto:jason.orendo...@gmail.com
Sent: 2014-06-17 15:22
To: Allen Wirfs-Brockmailto:al...@wirfs-brock.com
Cc: EcmaScriptmailto:es-discuss@mozilla.org; Mark
Millermailto:erig...@gmail.com
Subject: @@new
Allen asked me to fill out what @@new
What happens if I put [Symbol.new] on a non-function object? Is it now
constructable? Presumably still not callable though, right?
From: Jason Orendorffmailto:jason.orendo...@gmail.com
Sent: 2014-06-17 15:22
To: Allen Wirfs-Brockmailto:al...@wirfs-brock.com
Cc:
What about the other direction?
class B {
constructor(x) {
this.x = x;
}
static [Symbol.create]() {
var o = super();
weakMap.set(o, 12345678); // DOM wrapper foo
return o;
}
}
function C(x) {
B.call(this, x);
}
C.__proto__ = B;
C.prototype = {__proto__: B.prototype};
Another thing to consider is to ensure that @@create initializes all of its
slots. For example Date[@@create]() could set its [[DateValue]] to NaN,
Map[@@create]() could set its [[MapData]] to an empty list and so on.
This also fits how @@create works for DOM, where the creation of the
instance
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Boris Zbarsky
bzbar...@mit.edu
While true, I'd like to see a concrete proposal about how we actually proceed
with making the web platform subclassable in the @@create world. Whereas in
the @@new world subclassibility by default
Another thing to consider is to ensure that @@create initializes all of
its slots. For example Date[@@create]() could set its [[DateValue]] to NaN,
Map[@@create]() could set its [[MapData]] to an empty list and so on.
I think if you go that route you still may need some checks in place to
On Wed, Jun 18, 2014 at 8:55 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What happens if I put [Symbol.new] on a non-function object? Is it now
constructable? Presumably still not callable though, right?
Yes, it would be constructable but still not callable.
-j
On 6/18/14, 11:39 AM, Erik Arvidsson wrote:
This also fits how @@create works for DOM, where the creation of the
instance would set up the internal DOM wrapper pointer, never exposing a
non initialized DOM object to user code.
Note that in that setup it's impossible to introduce an HTMLElement
On 6/18/14, 12:09 PM, Domenic Denicola wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Boris Zbarsky
bzbar...@mit.edu
While true, I'd like to see a concrete proposal about how we actually proceed
with making the web platform subclassable in the @@create world. Whereas in
On Jun 18, 2014, at 8:33 AM, Erik Arvidsson wrote:
I think the most concerning part of this proposal is that `constructor(...)`
gets replaced by `static [Symbol.new](...)` with strange semantics regarding
`this`. If we instead had @@new call constructor by default I think most of
these
On Jun 18, 2014, at 8:39 AM, Erik Arvidsson wrote:
Another thing to consider is to ensure that @@create initializes all of its
slots. For example Date[@@create]() could set its [[DateValue]] to NaN,
Map[@@create]() could set its [[MapData]] to an empty list and so on.
This also fits how
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
So this is basically option 2 from
https://mail.mozilla.org/pipermail/es-discuss/2014-June/037849.html if I
understand right?
Yes, although in this case no initialization checks are necessary, just brand
checks. Which I guess speaks to your point
On Wed, Jun 18, 2014 at 1:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/18/14, 11:39 AM, Erik Arvidsson wrote:
This also fits how @@create works for DOM, where the creation of the
instance would set up the internal DOM wrapper pointer, never exposing a
non initialized DOM object to user
I held back but can't any longer.
Till Schneidereit wrote:
As far as I can tell, toString being an issue is just a conjecture
that hasn't been tested. So, you could even go ahead an implement
the corresponding toString methods as currently stands in the ES6
spec. (throw for
Allen Wirfs-Brock wrote:
This is also one of my bigger concerns. I think the rewriting and
reinterpretation of what the use wrote as a a constructor may be very
problematic. For example,how does this get translated:
class extends C {
constructor() {
super();
super.foo();
Domenic Denicola wrote:
I am not sure there are too many cases where there's an interesting distinction
between allocated and initialized for the DOM, though. Given how few DOM
objects have reasonable constructors to begin with, it seems like most of their
work is being done (conceptually) in
On Wed, Jun 18, 2014 at 1:40 AM, David Herman dher...@mozilla.com wrote:
You're inlining the method body into the @@new body, but I want to make sure
I understand what the specification of the Point function itself would be.
You've said Point !== Point[@@new] but calling Point(...args) should
On Jun 18, 2014, at 11:09 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
This is also one of my bigger concerns. I think the rewriting and
reinterpretation of what the use wrote as a a constructor may be very
problematic. For example,how does this get translated:
class extends C {
On Wed, Jun 18, 2014 at 2:18 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
I had a syntactic restriction on `super` for two reasons, neither one
related to the kind of invariant you're thinking of: (1) if the
super() call isn't there, I wanted to call it implicitly, for
convenience and
On Jun 18, 2014, at 11:18 AM, Jason Orendorff wrote:
If so it seems like the question of whether to keep or drop the `new super`
syntax is 100% orthogonal to your proposal.
I think that's right. I assumed the use cases for `new super` must be
something to do with how objects are
Allen Wirfs-Brock wrote:
Except in the current design there is no special reinterpretation of
the constructor method body semantics. The constructor method
definition simply provides body of the constructor function and
semantically is exactly the same as the body that is provided in a
Brendan Eich wrote:
Still, here
Er, there
are some other bits of magic that make constructor(){} as ClassElement
not just a method definition. Here's another:
* 'constructor' is not enumerable but methods are.
Someone should compile the complete list.
/be
On Wed, Jun 18, 2014 at 1:04 PM, Brendan Eich bren...@mozilla.org wrote:
Just use Invalid Date and get on with more important work. My 2 cents.
Endorse. Can we get that added to the spec as normative text? ;-)
-j
___
es-discuss mailing list
From: Brendan Eich bren...@mozilla.org
This all looks at the past, where the DOM is warty as hell (I can say that, I
started it). What about the future?
Much the same, from what I understand. The parser needs to be able to create
elements, including custom elements, without knowing what
On Wed, Jun 18, 2014 at 2:54 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Brendan Eich bren...@mozilla.org
This all looks at the past, where the DOM is warty as hell (I can say
that, I started it). What about the future?
Much the same, from what I understand. The parser
On 6/18/14, 1:46 PM, Domenic Denicola wrote:
Yes, although in this case no initialization checks are necessary, just brand
checks.
Well. That depends on the desired behavior.
For example, say you have a DOMPoint as in your example above that is
supposed to return Numbers for x and y.
In
On 6/18/14, 2:54 PM, Domenic Denicola wrote:
Much the same, from what I understand. The parser needs to be able to create
elements, including custom elements
Most DOM objects being added nowadays are not elements at all. We
need a less ambiguous name for web platform things. I've sometimes
On 6/18/14, 1:58 PM, Erik Arvidsson wrote:
This particular one can be done because if the constructor returns an
object that is used instead.
Ah, I see.
This is an ugly pattern so it is discouraged
Especially given that it requires special care when subclassing somethin
with such a
On Jun 18, 2014, at 11:41 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Except in the current design there is no special reinterpretation of the
constructor method body semantics. The constructor method definition simply
provides body of the constructor function and semantically is
On Wed, Jun 18, 2014 at 9:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that at this point we're already forcing spec authors to think about
the exact @@create behavior to make things subclassable and that in
particular, every single existing spec that has a constructor will need to
be
On Wed, Jun 18, 2014 at 3:08 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I think that fact that these really are semantically equivalent:
function F(x) {this.foo=x};
class F {constructor(x) {this.foo=x}};
is pretty important to the evolutionary nature ES6 classes.
That's the easy
Allen Wirfs-Brock wrote:
Not so much to me, and one could argue for static [@@new](){} sugar similarly.
I think that fact that these really are semantically equivalent:
function F(x) {this.foo=x};
class F {constructor(x) {this.foo=x}};
is pretty important to the evolutionary nature ES6
On 6/18/14, 3:14 PM, Anne van Kesteren wrote:
Revisiting existing classes and making them suitable for subclassing
seems like something that would be hard to avoid.
I think the difference for me is whether making a class subclassable
before careful auditing means potentially introducing
On Jun 18, 2014, at 1:43 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Not so much to me, and one could argue for static [@@new](){} sugar
similarly.
I think that fact that these really are semantically equivalent:
function F(x) {this.foo=x};
class F {constructor(x)
function F(x) { /* ??? the initial message really isn't explicit about
what does here */ };
F[Symbol.new] = {[Symbol.new](x) { //use an object literal to create a
method kind of function
var obj = super();
obj.foo = x
}}[Symbol.new].toMethod(F);
which is quite different
On Jun 18, 2014, at 11:04 AM, Brendan Eich wrote:
I held back but can't any longer.
Till Schneidereit wrote:
As far as I can tell, toString being an issue is just a conjecture
that hasn't been tested. So, you could even go ahead an implement
the corresponding toString methods
Allen Wirfs-Brock wrote:
Mostly about establishing the pattern for what should be done for other toString methods
that are applied to the wrong kind of object or a non-instance prototype. Not every
object that could get a custom toString has a natural 0-value.
Don't let the tail wag the dog
On Wed, Jun 18, 2014 at 2:38 PM, Brendan Eich bren...@mozilla.org wrote:
[...] Throw if no zero might go a long way, cover most of the dog.
Is there a cartoonist in the house?
/be
--
Cheers,
--MarkM
___
es-discuss mailing list
On Jun 18, 2014, at 2:38 PM, Brendan Eich wrote:
For example, what should Symbol.prototype.toString() do? (b) sounds like a
good choice for it. (c) is certainly ok, for Date.prototype but but we have
other cases that need to be addressed.
Symbol.prototype could even throw, it's such
I think Allen's suggestion of providing constructor arguments to @@create
is promising. That would allow the implementation to allocate and
initialize an object in one go, if desired. That seems to embody the
advantages of fusing initialization and allocation, without the headache
for the user.
Allen Wirfs-Brock wrote:
The spec. current says throw for this Symbol.prototype case. The
(reasonable) opposing view is that toString should never throw. Other
than the protoype-is-not-an-instance it all about unlikely edge cases
where toString methods are applied to the wrong kind of
On Jun 18, 2014, at 4:12 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The spec. current says throw for this Symbol.prototype case. The
(reasonable) opposing view is that toString should never throw. Other than
the protoype-is-not-an-instance it all about unlikely edge cases where
For background, here is the original proposal presentation about using @@create
to enable subclassing of built-ins.
http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_jan_29_2013cache=cachemedia=meetings:subclassing_builtins.pdf
In particular see material that starts at
Allen Wirfs-Brock wrote:
[ object ???]
[object WTF]
:-P
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
50 matches
Mail list logo
