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
I really like this proposal.
2014-06-17 21:32 GMT+02:00 C. Scott Ananian :
> +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 handled with the usual
On Tue, Jun 17, 2014 at 11:11 PM, Brendan Eich wrote:
> I think Jason's proposal leaves this C C[Symbol.new] condition a
> separate choice from everything else, and choosing the way you prefer does
> not break the rest of the design. Jason?
Yes, that's correct.
-j
__
Kevin Smith wrote:
Sorry for my previous gut reaction. This looks like a good proposal,
but it makes a break with the evolutionary design of ES classes.
How so? @@create or @@new, either way something in ES6 is new that was
not in classes-desugared-to-functions.
Furthermore, when we were ha
Boris Zbarsky wrote:
If we _can_ have a world in which web platform objects don't exist in
constructed-but-not-initialized states, I personally would much prefer
that
+ΒΆ
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla
Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
> See Allen's latest followup on this -- is it a static error to have both
constructor and the static [Symbol.new]() method?
IMO it shouldn't be, because it'd be weird to get an error
This is upside down in my opinion ... Me, as a service, would like yo
notify you based on where you are. You as a user with a specific
timezone in mind can always ask for it explicitly ... I'm thinking
about navigations based on your location, not something easy to
polifill client side only via som
On 6/17/14, 8:47 PM, Allen Wirfs-Brock wrote:
You mean, the already initialized checks which fall out of objects having
distinct allocation and initialization functions. Those checks only occur in
functions that directly access private internal state of built-in oibjects.
I should note that
On Tue, Jun 17, 2014 at 7:27 PM, Norbert Lindenberg <
ecmascr...@lindenbergsoftware.com> wrote:
> The time zone the user wants to use, and therefore sets in the OS, is not
> always tied to the current location. For example, on a flight from San
> Francisco to Frankfurt I care about Pacific Time an
The time zone the user wants to use, and therefore sets in the OS, is not
always tied to the current location. For example, on a flight from San
Francisco to Frankfurt I care about Pacific Time and Central European Time, but
not the other time zones I fly over. There are also locations for which
Even if the OS doesn't provide notifications, the implementation could poll
in order to synthesize notifications. Given that the issue is time zone
changes, the polling interval could be rather large without complaint,
except from astronauts and east/west hyperloop travelers ;).
On Tue, Jun 17, 2
On Jun 17, 2014, at 17:28 , David Herman wrote:
> This was brought up on specifiction:
>
>http://discourse.specifiction.org/t/navigator-timezone/152
>
> Does anyone know why it was left out of the first version of the Intl API?
> Just for lack of time? Is it planned for the next edition?
>
>
>> SyntaxError.
>>
>> > We could prevent this behavior by making sure that super(); must be the
>> > first statement in a constructor, [...]
>>
>> That is what I proposed.
>>
>
Sorry for my previous gut reaction. This looks like a good proposal, but
it makes a break with the evolutionary desig
without reinventing the wheel or changing it, I think timezone is very
close to geolocation so why not
navigator.geolocation.getTimeZone(*success*, *error*)
asd
navigator.geolocation.watchTimeZone(*success*, *error*)
?
On Tue, Jun 17, 2014 at 5:31 PM, Domenic Denicola <
dome...@domenicdenic
On Jun 17, 2014, at 5:22 PM, Allen Wirfs-Brock wrote:
>
> On Jun 17, 2014, at 4:44 PM, Brendan Eich wrote:
>
>> ... especially since I missed the hideous Number special-casing spread
>> around in the draft!
>
> could you be a bit more specific about what you are referring to?
Never mind, I t
On Jun 17, 2014, at 5:31 PM, Domenic Denicola
wrote:
>> Interesting questions in that thread about what to do about time zone
>> changes. An event for time zone changes seems important, but we don't
>> currently have any precedent for standard library events in ECMAScript.
>
> Object.observe
On Tue, Jun 17, 2014 at 4:02 PM, Jason Orendorff
wrote:
> On Tue, Jun 17, 2014 at 2:49 PM, Jasper St. Pierre
> wrote:
> > How would
> >
> > constructor() {
> > if (rand() > 0.5)
> > super("A");
> > }
> >
> > behave?
>
> SyntaxError.
>
> > We could prevent this behavio
On Tue, Jun 17, 2014 at 5:28 PM, David Herman wrote:
> Does anyone know why it was left out of the first version of the Intl API?
> Just for lack of time? Is it planned for the next edition? Are there tricky
> issues around standardizing IANA time zones, or around incompatibilities
> between diff
> Interesting questions in that thread about what to do about time zone
> changes. An event for time zone changes seems important, but we don't
> currently have any precedent for standard library events in ECMAScript.
Object.observe change records? A synthetic change event seems perfect for this
This was brought up on specifiction:
http://discourse.specifiction.org/t/navigator-timezone/152
Does anyone know why it was left out of the first version of the Intl API? Just
for lack of time? Is it planned for the next edition? Are there tricky issues
around standardizing IANA time zones,
On Jun 17, 2014, at 4:44 PM, Brendan Eich wrote:
> ... especially since I missed the hideous Number special-casing spread around
> in the draft!
could you be a bit more specific about what you are referring to?
Allen
___
es-discuss mailing list
es-di
Mutable bindings have valid use cases for object properties as well. My - very
late - vote is for modules to use the same destructuring syntax as objects.
Just leave out mutable bindings in modules for now. That way both modules and
objects use the same syntax and that syntax means the same th
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
> See Allen's latest followup on this -- is it a static error to have both
> constructor and the static [Symbol.new]() method?
IMO it shouldn't be, because it'd be weird to get an error for `constructor` +
`stat
On Tue, Jun 17, 2014 at 6:55 PM, Erik Arvidsson
wrote:
> How does this work with legacy classes?
>
> function B() {
> this.x = 1;
> }
> class C extends B {}
That works!
`new C` desugars to `C[@@new]()`. C doesn't have a @@new method of
its own, so it inherits `Function.prototype[@@new]`.
The
On Jun 17, 2014 7:44 PM, "Brendan Eich" wrote:
>
> So far, I prefer your proposal to draft ES6 by a lot -- especially since
I missed the hideous Number special-casing spread around in the draft!
I don't.
How does this work with legacy classes?
function B() {
this.x = 1;
}
class C extends B {}
I realized I'm not sure how my [ClassMix library](
https://gist.github.com/bterlson/fc94a81a3811f48187b6#file-mix-js) will work
with this proposal, if at all. Clearly the subclass constructor in [the
example](https://gist.github.com/bterlson/fc94a81a3811f48187b6#file-exampleapp-js-L15)
would ha
So far, I prefer your proposal to draft ES6 by a lot -- especially since
I missed the hideous Number special-casing spread around in the draft!
Jason Orendorff wrote:
> Is `C === C[@@new]`?
Good question. I think calling `C(...args)` should be the same as
calling `new C(...args)`. How best t
On Jun 17, 2014, at 1:02 PM, Jason Orendorff wrote:
> On Tue, Jun 17, 2014 at 2:49 PM, Jasper St. Pierre
> wrote:
>> How would
>>
>>constructor() {
>>if (rand() > 0.5)
>>super("A");
>>}
>>
>> behave?
>
> SyntaxError.
>
>> We could prevent this behavior by making s
>
>
> > constructor() {
> > if (rand() > 0.5)
> > super("A");
> > }
> >
> > behave?
>
> SyntaxError.
>
> > We could prevent this behavior by making sure that super(); must be the
> > first statement in a constructor, [...]
>
> That is what I proposed.
>
Sorry, but I can
On Tue, Jun 17, 2014 at 4:24 PM, Dmitry Soshnikov
wrote:
>> Anyway --- skipping a base class constructor is not a normal thing to
>> do. It shouldn't be the default.
>
> That's the question. I guess there could valid cases when you wanna call
> parent constructor conditionally as was shown, or to
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, appropriate degenerate value, which is
> generally the zero value, but is
I like this proposal overall. Another benefit is that your super class
constructors can return objects and things will just work (I think?).
I'm of the opinion that new should be required. Perhaps for `class C { }`, C is
a function as if created by the expression `function () { throw('Class must
On Tue, Jun 17, 2014 at 1:02 PM, Jason Orendorff
wrote:
> On Tue, Jun 17, 2014 at 2:49 PM, Jasper St. Pierre
> wrote:
> > How would
> >
> > constructor() {
> > if (rand() > 0.5)
> > super("A");
> > }
> >
> > behave?
>
> SyntaxError.
>
>
Ouch.. Don't know, there are se
On Jun 17, 2014, at 1:53 PM, Domenic Denicola wrote:
>> It sounds like the the tide is swinging towards bug finding rather than
>> consistency in this case. I'm fine with and and will update the spec.
>> accordingly.
>
> The conclusion here wasn't exactly clear to me. Is it the following?
>
> It sounds like the the tide is swinging towards bug finding rather than
> consistency in this case. I'm fine with and and will update the spec.
> accordingly.
The conclusion here wasn't exactly clear to me. Is it the following?
- for-in continues to do zero iterations
- for-of throws a TypeE
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, appropriate degenerate value, which
> is generally the zero value, but is plausibly NaN for Date.
>
> Whichever experiment Nightly tr
On Tue, Jun 17, 2014 at 2:55 PM, Erik Arvidsson
wrote:
> What would `C.prototype.constructor` look like with your proposal?
ES6 already achieves `C.prototype.constructor === C`, for both
functions and classes, simply by defining the two properties that way
(in [1] steps 6 and 7). I wouldn't chang
https://twitter.com/slightlylate/status/475089406957604864
Take care
On Tue, Jun 17, 2014 at 11:47 AM, Alex Russell
wrote:
> On Tue, Jun 17, 2014 at 11:46 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> FWIW I think this is a non issue and "how many" should not be relevant.
On Tue, Jun 17, 2014 at 2:49 PM, Jasper St. Pierre
wrote:
> How would
>
> constructor() {
> if (rand() > 0.5)
> super("A");
> }
>
> behave?
SyntaxError.
> We could prevent this behavior by making sure that super(); must be the
> first statement in a constructor, [...]
Remember that
```js
class C {
constructor() {}
}
assert(C === C.prototype.constructor);
```
What would `C.prototype.constructor` look like with your proposal? Is `C
=== C[@@new]`?
On Tue Jun 17 2014 at 3:22:05 PM, Jason Orendorff
wrote:
> Allen asked me to fill out what @@new would mean. Her
On Tue, Jun 17, 2014 at 12:36 PM, C. Scott Ananian
wrote:
> My guess would be that `catch` is reserved so that (in a future
> version of JavaScript) this won't be ambiguous:
> ```
> try { stuff(); }
> catch(e1) { }
> catch(e2) { }
> ```
>
> Currently JS only allows a single catch clause.
FWIW:
On Tue, Jun 17, 2014 at 3:21 PM, Jason Orendorff
wrote:
> Allen asked me to fill out what @@new would mean. Here it is.
>
... snip ...
> The "super Arguments" call syntax in the ES6 drafts would be constrained to
> appear only at the top of a constructor, as in Java:
>
> class PowerUp {
>
That's a great point, thanks.
On 6/17/14, 12:36 PM, C. Scott Ananian wrote:
My guess would be that `catch` is reserved so that (in a future
version of JavaScript) this won't be ambiguous:
```
try { stuff(); }
catch(e1) { }
catch(e2) { }
```
Currently JS only allows a single catch clause. But i
My guess would be that `catch` is reserved so that (in a future
version of JavaScript) this won't be ambiguous:
```
try { stuff(); }
catch(e1) { }
catch(e2) { }
```
Currently JS only allows a single catch clause. But if it ever grows
guarded catch expressions, then you would want to add multiple
+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 handled with the usual proxy
method dispatch mechanism. I'll leave it to someone who better
understands Proxie
I was just talking with a co-worker today about why it's ok for 'catch'
to be a property name, but not a variable identifier. It's clear that
the reasoning here is because property names aren't restricted by
reserved words, but it's unclear why 'catch' must be reserved to begin with?
I had alw
Allen asked me to fill out what @@new would mean. Here it is.
## How `new X` works
`new X(...args)` `X[@@new](...args)`
## How it works for ES5 builtin constructors
`Number(value)` is specified in one section.
`Number[@@new](value)` is specified in another section.
To support subclassi
On Tue, Jun 17, 2014 at 11:46 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> FWIW I think this is a non issue and "how many" should not be relevant.
>
> If developers understand the issue, the fix is straight forward.
>
I wish to live in your world of unicorns and magic for in that
FWIW I think this is a non issue and "how many" should not be relevant.
If developers understand the issue, the fix is straight forward.
instead of doing this
```javascript
if (obj.entries) {
// do stuff with entries
} else if(Array.isArray(obj)) {
// do stuff with obj
}
```
or this
`var e
Right. Would love to know the size/traffic of the "number of sites"
affected.
On Tue, Jun 17, 2014 at 10:45 AM, Rick Waldron
wrote:
>
>
>
> On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich
> wrote:
>
>> Would .items fare better, I wonder.
>>
>
> Or outreach to sites the break?
>
> Rick
>
>
>>
>
On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich wrote:
> Would .items fare better, I wonder.
>
Or outreach to sites the break?
Rick
>
> /be
>
> Oliver Hunt wrote:
>
>> It turns out there are a number of sites (such as mobile.twitter.com <
>> http://mobile.twitter.com>) that are property detect
Holy goodness http://www.collectionsjs.com/
On Jun 9, 2014 10:33 PM, "Tab Atkins Jr." wrote:
> On Mon, Jun 9, 2014 at 8:33 AM, Erik Arvidsson
> wrote:
> > Most of these could just be methods of iterators and then they could be
> used
> > for different data structures seemlessly.
>
> In other wor
I am happy with #b as well, though I prefer #c. I also agree with C.
Scott's interpretation of #c, to mean, appropriate degenerate value, which
is generally the zero value, but is plausibly NaN for Date.
Whichever experiment Nightly tries first with a positive outcome, I expect
that's what we'll d
On Tue, Jun 17, 2014 at 11:33 AM, Allen Wirfs-Brock
wrote:
> I'm not sure who introduced the idea that the Date.prototype should have a
> "zero value", but that is inconsistent with ES3&5 where the TimeValue of
> Date.prototype is NaN:
> http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.5 I
On Jun 17, 2014, at 2:10 AM, Till Schneidereit wrote:
> On Thu, Jun 12, 2014 at 10:42 PM, C. Scott Ananian
> wrote:
> On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller wrote:
> > I like this list. I prefer #c.
> > * We have previously succeeded at making previously non-generic methods
> > generi
I guess there is no technical argument that will convince you. Thanks for
at least having the discussion, more than we got before.
jjb
On Mon, Jun 16, 2014 at 9:02 PM, caridy wrote:
> John, there are a couple of solutions at hand that you can apply:
>
> 1. loader provides the right hooks for y
There are two options for prefetching dependencies without having to wait for
"load" and "parse":
1) Assume none of your modules use the loader object for loading other modules,
parse them during deployment and get the dependency graph.
2) Use what Guy calls a "tracer" that executes your app dur
Trying #c on Nightly would provide us the information needed to bring #c to
consensus.
On Tue, Jun 17, 2014 at 2:10 AM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Thu, Jun 12, 2014 at 10:42 PM, C. Scott Ananian
> wrote:
>
>> On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller
>> wr
On Thu, Jun 12, 2014 at 10:42 PM, C. Scott Ananian
wrote:
> On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller
> wrote:
> > I like this list. I prefer #c.
> > * We have previously succeeded at making previously non-generic methods
> > generic. I think we could get away with #c.
> > * It is easier f
59 matches
Mail list logo
