Re: Standard builtins' prototypes and toString

Allen Wirfs-Brock wrote: "[ object ???]" "[object WTF]" :-P /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: @@new

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_2013&cache=cache&media=meetings:subclassing_builtins.pdf In particular see material that starts at sl

Re: Standard builtins' prototypes and toString

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 whe

Re: Standard builtins' prototypes and toString

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 object.

Re: @@new

> 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.

Re: Standard builtins' prototypes and toString

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, i

Re: Standard builtins' prototypes and toString

On Wed, Jun 18, 2014 at 2:38 PM, Brendan Eich 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 es-discuss@moz

Re: Standard builtins' prototypes and toString

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 do

Re: Standard builtins' prototypes and toString

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 toSt

Re: @@new

> > > 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 d

Re: @@new

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

Re: @@new

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 subopt

Re: @@new

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 c

Re: @@new

On Wed, Jun 18, 2014 at 3:08 PM, Allen Wirfs-Brock 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 case. The `clas

Re: @@new

On Wed, Jun 18, 2014 at 9:01 PM, Boris Zbarsky 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 revisited and mo

Re: @@new

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

Re: @@new

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 constru

Re: @@new

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 someti

Re: @@new

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 y

Re: @@new

On Wed, Jun 18, 2014 at 2:54 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > From: Brendan Eich > > > 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

RE: @@new

From: Brendan Eich > 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 their constructor sig

Re: Standard builtins' prototypes and toString

On Wed, Jun 18, 2014 at 1:04 PM, Brendan Eich 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 es-discuss@mozilla.org http

Re: @@new

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 _

Re: @@new

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 Functi

Re: @@new

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 cons

Re: @@new

On Wed, Jun 18, 2014 at 2:18 PM, Jason Orendorff 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 correctness-by-default

Re: @@new

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 ex

Re: @@new

On Wed, Jun 18, 2014 at 1:40 AM, David Herman 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 behave > the sa

Re: @@new

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

Re: @@new

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(); //

Re: Standard builtins' prototypes and toString

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 the

Re: @@new

On Wed, Jun 18, 2014 at 1:07 PM, Boris Zbarsky 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 code. >>

RE: @@new

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

Re: @@new

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

Re: @@new

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

Re: @@new

On 6/18/14, 12:09 PM, Domenic Denicola wrote: From: es-discuss on behalf of Boris Zbarsky 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 is

Re: @@new

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

Re: @@new

On Wed, Jun 18, 2014 at 8:55 AM, Domenic Denicola 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 __

Re: @@new

> 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

RE: @@new

From: es-discuss on behalf of Boris Zbarsky > 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 is at least somewhat viable... Hmm, I though

Re: @@new

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 wo

Re: @@new

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};

RE: @@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 Orendorff Sent: ‎2014-‎06-‎17 15:22 To: Allen Wirfs-Brock

RE: @@new

From: Jason Orendorff Sent: ‎2014-‎06-‎17 15:22 To: Allen Wirfs-Brock Cc: EcmaScript; Mark Miller Subject: @@new Allen asked me to fill out wha

Re: @@new

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 @

Re: @@new

On 18 June 2014 09:40, Dmitry Soshnikov wrote: > On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff > 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 >

Re: Standard builtins' prototypes and toString

On Tue, Jun 17, 2014 at 11:27 PM, Allen Wirfs-Brock wrote: > > On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote: > > On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller wrote: > >> I am happy with #b as well, though I prefer #c. I also agree with C. >> Scott's interpretation of #c, to mean, appropr

Re: @@new

On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff 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 (for example) can