Re: excluding features from sloppy mode
I believe the only major factors in usage uptake for ES6 will be in the ever present need for backwards compatibility, and educating developers on what new tools exist. Imdo not believe having a "use strict" gatekeeper at the front of the ES6 bonanza would not be a motivating factor in turning people away. "I really wish I could use destructuring and arrow functions and generators and iterators and...*a dozen more carrots*, but this strict mode thing is just a bridge too far." I cannot see that thought process actually going through anyone's mind. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL attribute reflection
On 12/29/12 10:42 PM, Boris Zbarsky wrote: If I'm not misreading the code, it actually hangs its DOM property getters/setters of the prototype internally, makes them look like own properties on objects when reflected via getOwnPropertyDescriptor, and has magic to make a property lookup return the getter/setter pair internally and have their interpreter and JIT call those. One other note. SpiderMonkey used to have some things sort of like this (though not quite as well-integrated with the JIT); I believe they've been actively trying to remove them precisely because they end up being a pain to reflect in terms of property descriptors. The line I've heard from that direction has been to use proxies for weird stuff, getter/setters or real value properties for non-weird stuff. Now obviously you can use proxy semantics to describe even things that don't really _need_ to be all that weird. When you have a hammer and all... ;) -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL attribute reflection
On 12/29/12 11:08 AM, David Bruant wrote: Boris, what initially triggered my questioning of the inherited accessor setting is in this message: https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html OK, but that's a problem methods can have too, yes? Not in this particular case, but in plenty of other cases... Completely revamping how properties are handled to make this one case easier seems a bit extreme. In my opinion. That said, thank you for the pointer. I do agree that this particular case would be a bit simpler if .global were an own property. Mostly concerns about a mix of API "securability" and convenience. I "demonstrate" that if every attribute is an inherited accessor, then, it's possible to secure the environment, but it can be at the expense of API usability up to asking people to tweak their code (which is an anti-goal when trying to secure your code from, say, an advertiser's code) If you're trying to secure your code from an advertiser's code you want to not run the advertiser's code with your origin. Anything else at best gives you the illusion of security... Again, in my opinion. Implementations are free to do whatever they want as long as the observable behavior is conformant. Yes, I understand that. My point is that this makes it too easy to spec overcomplicated things that in fact can't be optimized sanely by implementations unless the specification writers are _very_ careful. WebIDL tries to close the gap between DOM semantics and ECMAScript semantics. Yes, while at the same time converging with implementations. In an ES5 world, the only thing that can explain the magic behavior is getters/setters (own or inherited). In an ES6 world, proxies can be an explanation too. Yes. For some cases like WindowProxy or NodeList, there will be no other way than using proxies to specify these objects in an ECMAScript replicable semantics. Indeed. I'm not sure I'm convinced by "it's more work than right now". If you had told me that there is a fundamental issue that implementors can't work around when exposing own data properties, I would have backed out, but you suggested than it's possible to create "yet another kind of thing internally which is not a proxy so it can be optimized sanely". This is empirically true, since that's what JavaScriptCore does today, for example. If I'm not misreading the code, it actually hangs its DOM property getters/setters of the prototype internally, makes them look like own properties on objects when reflected via getOwnPropertyDescriptor, and has magic to make a property lookup return the getter/setter pair internally and have their interpreter and JIT call those. So in JavaScriptCore there are at least three different kinds of properties (there are more, because they have non-proxy objects with custom getOwnPropertyDescriptor hooks, like Document, but I'm simplifying): accessor properties, value properties, and magic properties that claim to be value properties when reflected but don't have a slot, are actually accessor properties under the hood, and pretend to be on a different object than the object they're really on. This of course has the interesting side-effect that JavaScriptCore ends up having to claim the properties are non-configurable, because they don't actually live on the objects under the hood, so you have to disallow deleting them. So this approach, in this particular implementation, doesn't address you "delete .global" issue anyway. Try the testcase: var h = document.documentElement; alert(h.innerHTML); alert(JSON.stringify(Object.getOwnPropertyDescriptor(h, "innerHTML"))); delete h.innerHTML; alert(h.innerHTML); Is there some sort of way to use the getter/setter based implementation, but expose things as data property when asked via Object.getOwnPropertyDescriptor? See above. Again, in computer science pretty much everything is possible. It's all just code. It's doing the thing you want in finite time, both implementation time and run time, is the hard part. Out of curiosity, do you have an idea of how much cost the |this| check? Cost in terms of what? It depends on your implementation, obviously (e.g. it's really expensive in Gecko's XPConnect bindings from 6 years ago), but in Gecko's WebIDL bindings the cost of the "this" check (which we want to minimize no matter what, because methods have to do it!) is about 15-20 cycles on average last I measured (including whatever cache misses are involved every so often, etc). It'll get a bit cheaper as we remove some more edge cases it has to deal with right now. Oh, and in practice we usually only have to do it at JIT-compile time, not at runtime (unless you go out of your way to do .call or .apply on the getter/setter) because the combination of the type inference and guarding the JIT already does means that we'll get the
Re: excluding features from sloppy mode
> 1) All new syntax and breaking changes (where possible) are strict-mode
>> only.
>> 2) Modules and only modules are implicitly strict.
>>
>
> (2) is not what (1) says, ignoring the mysterious "(where possible)"
> loophole.
>
You're really sharp! Notice that I didn't specify in or out-of-line
modules there. Originally, I was going to close the loophole by saying
that only out-of-line modules get implicit strict, but I waffled... Nice
catch!
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
> Ease of teaching != successfully imparted knowledge at scale. Sorry, but
> it's true. People don't use "use strict"; at top level enough, and teaching
> them all will take time. Even then, because of the Law of Least Effort,
> it'll be left out.
>
> This is the major objection some of us keep raising, and you don't engage
> with it. Please do!
Sure - my answer is: modules, classes, arrows, and templates. Those
carrots are so sweet that no developer will be able to resist them. I tend
to overstate, I know, but they are game-changers!
> - It creates a clean, linear evolution for javascript syntax: ES3 > ES5
>> strict > ES6 > ES7.
>>
>
> I would use < for that relation, but it's not a subset relation due to the
> non-early-error, runtime-semantic-shifts of ES5 strict.
>
Yep - should have been "<", and it's loose as you say.
> Also, enough pretty (if inaccurate) diagrams! User-facing complexity,
> developer ergonomics, usability matter more than Platonic prettiness.
> There, I said it :-P.
Yep - elegance is my siren song. But if there is a place for Platonic
prettiness, then it must be in the language itself.
> - It eliminates the so-called "micro-modes" in function heads.
>>
>
> A canard, or at most a quibble about banning duplicate formals in the
> present of destructuring, which I am prepared to negotiate away. Please
> don't repeat it carelessly.
Fair enough.
> - It gets everyone moving in the same direction: strict mode.
>>
>
> In your dreams, but in reality the sprawl is large and in several
> direction.
Well, my take is that people just like to talk tough.
> - It eliminates subjective questions about what constructs should be
>> implicitly strict.
>>
>
> There's nothing subjective about such questions, any more than your
> contentions about strict mode being objective. In practice people will not
> use strict when they might, and making ES6 features available only under
> "use strict" will, ceteris paribus, lead to less adoption of ES6 than
> otherwise.
Again, the sweetness of the carrots tell me otherwise.
> and breaking changes (where possible)
>
> Why the "(where possible)"?
>
Because not being a runtime implementor (not yet anyway), I can't comment
on where it might be impractical to have bifurcated semantics.
If you believe in strict mode so strongly, why not make all new syntax with
> a body-form be implicitly strict in that body's code?
>
Platonic prettiness : )
> 2) Modules and only modules are implicitly strict.
>>
>
> Whew! You seemed to throw this out in your lede, really till here.
Modules are the lynchpin!
I know, you're tired of hearing from me.
>
Are you kidding? Not one bit!
> I'll subside for a while. However, you know there are issues with strict
> mode, not all "superstition". Ignoring them, pretending they do not hamper
> adoption, dodges the central objection to your proposal: that by yoking ES6
> feature adoption to strict mode adoption, you multiply risks and reduce ES6
> adoption.
>
I understand the concern, really. But I would say that given the sweetness
of the carrots, it rather eliminates the risk of strict mode non-adoption.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: excluding features from sloppy mode
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] > On Behalf Of Brendan Eich > Sent: Sunday, December 30, 2012 00:06 > by yoking ES6 feature adoption to strict mode adoption, you multiply risks > and reduce ES6 adoption. I'd like to lend a little bit of defense to Kevin's ideas here. Namely, it seems easy to me to imagine the following: - "Oh cool, ES6 is in $MY_FAVORITE_JS_ENVIRONMENT!" - "Awesome lemme insert some arrow functions to clean up all these map and filter arguments" - "What's that, Mr. Compiler? You won't let me use arrow functions unless I put 'use strict' at the top of my file?" - "OK, whatever, that seems lame, but arrow functions are worth it." This is of course predicated on the code in question not being affected by the breaking changes of strict mode, which is probably true of most code written by early adopters today. To be clear, there's obviously a lot of subtle issues here, as Brendan has pointed out. I do find it somewhat unlikely though, that *if* strict mode was required for anything ES6-ish, people would give up their new toys rather than point a pragma at the top of their file. (Although, as I write that last sentence, I realize this isn't much different than suggested `use version 6` :-/) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: excluding features from sloppy mode
Sadly no, and can't quite seem to get any of the various code-searches on the
internet working. It would be worth doing one of those web-crawling experiments
we see from time to time, though.
> -Original Message-
> From: Brendan Eich [mailto:bren...@mozilla.com]
> Sent: Saturday, December 29, 2012 22:10
> To: Domenic Denicola
> Cc: Mark S. Miller; es-discuss@mozilla.org
> Subject: Re: excluding features from sloppy mode
>
> Domenic Denicola wrote:
> > Duplicate parameters are quite common in the following case:
> >
> > callSomething(function (_, _, whatIActuallyCareAbout) {});
>
> I've never seen that in JS. In ML, sure.
>
> Have you any links to cite?
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Kevin Smith wrote: The more I think about this, the more convinced I get that all new syntax and breaking changes (where possible) should be strict-mode only ... 1) All new syntax and breaking changes (where possible) are strict-mode only. 2) Modules and only modules are implicitly strict. (2) is not what (1) says, ignoring the mysterious "(where possible)" loophole. Your lede has the loophole too and talks about ease of teaching. I smell a rat! Teaching people a simplified but not-quite-true story is useful. It's done all the time. But that is teaching, not language design. The full truth has the module loophole. Why? Why not class bodies too? The teaching myth in your lede and up till near the end does not justify the loophole being only big enough to let module through. A general slippery slope preference for one exception rather than N > 1 exceptions, that works a bit better, but it is still a bit of special-pleading. As promised subsiding. I just had to follow up because on re-reading, I noticed the teaching trick you pulled off. It's a good trick, again -- don't get me wrong. But it is not enough for the expert users or the language designers and implemntors, who need to hear the whole truth and buy into it, spread it, and love it. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Kevin Smith wrote:
The more I think about this, the more convinced I get that all new
syntax and breaking changes (where possible) should be strict-mode
only. In retrospect, `let[x] = y;` changed everything. Here's why I
think "1JS under strict" is the best solution:
- How exactly would one teach that classes, arrows, etc. are all
available in sloppy mode, but "let" is not? The reason is obscure for
a casual user. It's going to seem arbitrary. On the other hand, "1JS
under strict" is quite easy to teach.
Ease of teaching != successfully imparted knowledge at scale. Sorry, but
it's true. People don't use "use strict"; at top level enough, and
teaching them all will take time. Even then, because of the Law of Least
Effort, it'll be left out.
This is the major objection some of us keep raising, and you don't
engage with it. Please do!
- It creates a clean, linear evolution for javascript syntax: ES3 >
ES5 strict > ES6 > ES7.
I would use < for that relation, but it's not a subset relation due to
the non-early-error, runtime-semantic-shifts of ES5 strict.
Also, enough pretty (if inaccurate) diagrams! User-facing complexity,
developer ergonomics, usability matter more than Platonic prettiness.
There, I said it :-P.
- It eliminates the so-called "micro-modes" in function heads.
A canard, or at most a quibble about banning duplicate formals in the
present of destructuring, which I am prepared to negotiate away. Please
don't repeat it carelessly.
- It gets everyone moving in the same direction: strict mode.
In your dreams, but in reality the sprawl is large and in several direction.
- It eliminates subjective questions about what constructs should be
implicitly strict.
There's nothing subjective about such questions, any more than your
contentions about strict mode being objective. In practice people will
not use strict when they might, and making ES6 features available only
under "use strict" will, ceteris paribus, lead to less adoption of ES6
than otherwise.
To be clear, I'm proposing that:
1) All new syntax
New syntax is not a breaking change (as you use that phrase).
and breaking changes (where possible)
Why the "(where possible)"?
are strict-mode only.
If you believe in strict mode so strongly, why not make all new syntax
with a body-form be implicitly strict in that body's code?
2) Modules and only modules are implicitly strict.
Whew! You seemed to throw this out in your lede, really till here.
Why not?
Lurkers out there! Would anyone be opposed to opting-in to new ES6
syntax by either (a) "use strict" or (b) modules?
I know, you're tired of hearing from me. I'll subside for a while.
However, you know there are issues with strict mode, not all
"superstition". Ignoring them, pretending they do not hamper adoption,
dodges the central objection to your proposal: that by yoking ES6
feature adoption to strict mode adoption, you multiply risks and reduce
ES6 adoption.
/be
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
The more I think about this, the more convinced I get that all new syntax
and breaking changes (where possible) should be strict-mode only. In
retrospect, `let[x] = y;` changed everything. Here's why I think "1JS
under strict" is the best solution:
- How exactly would one teach that classes, arrows, etc. are all available
in sloppy mode, but "let" is not? The reason is obscure for a casual user.
It's going to seem arbitrary. On the other hand, "1JS under strict" is
quite easy to teach.
- It creates a clean, linear evolution for javascript syntax: ES3 > ES5
strict > ES6 > ES7.
- It eliminates the so-called "micro-modes" in function heads.
- It gets everyone moving in the same direction: strict mode.
- It eliminates subjective questions about what constructs should be
implicitly strict.
To be clear, I'm proposing that:
1) All new syntax and breaking changes (where possible) are strict-mode
only.
2) Modules and only modules are implicitly strict.
Why not?
Lurkers out there! Would anyone be opposed to opting-in to new ES6 syntax
by either (a) "use strict" or (b) modules?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never seen that in JS. In ML, sure.
Have you any links to cite?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: excluding features from sloppy mode
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
From: Brendan Eich
Sent: 12/29/2012 20:16
To: Mark S. Miller
Cc: es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Mark S. Miller wrote:
> On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich wrote:
>> Mark S. Miller wrote:
>>> 2) Make a micro-mode, adding yet additional mode switching in order to
>>> supposedly avoid the complexity of dealing with one mode switch.
>> No, you are using micro-mode as an epithet without actually defining it in a
>> meaningfully different way from "new semantics for new syntax".
>
> If I have a function
>
> function foo(w, x, y) {
>var [a, b] = y;
>// use of a,b but not y in rest of body
> }
>
> and I change it to
>
> function foo(w, x, [a, b]) {
>// use of a,b but not y in rest of body
> }
>
> I have preserved its meaning. The change seems local to the individual
> parameter. But if I have a function
>
> function foo(x, x, y) {
Yes, but let me interject: no one does this. It's insane. A latent bug
or a quirk that deserves an early error.
>var [a, b] = y;
>// use of a,b but not y in rest of body
> }
>
> and I change it to
>
> function foo(x, x, [a, b]) {
>// use of a,b but not y in rest of body
> }
>
> now my second function is rejected.
Yes, with an early error.
Since no one does duplicate formal parameter in practice, this early
error is a good thing (tm).
> This demonstrates the
> "mode-nature" if you will of this rule.
Rather, new syntax gets new semantics.
We've shipped this for years in SpiderMonkey. I believe Rhino matches.
No one uses duplicate formals, so no one has ever complained.
> The rejection must be
> explained by a function-wide change of what the language accepts,
No, not function-wide! Purely function-head, more specifically the
parameter list.
> even
> though I changed only one parameter.
Parameter changes in ES6 have effects on the list. We don't allow more
than one rest parameter at the end, for example. Given
function f(a, b, ...r) {...}
If I try adding another ellipsis:
function f(a, ...b, ...r) {...}
I get an early error. Another good thing(tm), and no less local than
destructuring parameters banning duplicate params.
> OTOH, if destructuring is accepted only in strict code, then the
> rejection of destructuring is explained only by strictness rules.
"rejection of duplicate parameters"
Yes, that's the way to explain it via (1). And you are right that the
condition for rejection of duplicate formals becomes more than "in
strict code". It has to be "in strict mode || destructuring present in
parameter list".
However, since duplicate formals are a do-not-want, always-a-bug,
freakish rarity bestowed on ES1 during standardization, this extra
disjunct is a spec-internal complexity, not anything users must worry about.
I'm prepared to give up on the ban of duplicate formals when
destructuring parameters are present, if that will get rid of your
objection to "micro-modes". I don't recall anything else like this case.
We arrived at it mainly to simplify implementation in SpiderMonkey, but
again: users do not notice because no one uses duplicate formals.
>> Are arrow functions, syntax and definite semantics, a "micro-mode"? If not,
>> why not? I suspect you are using a mental desugaring spec but there's no
>> such spec. Allen has to deal with whether arrows have [[Construct]] (we
>> decided no, because |this| is bound to outer |this|). Is that a
>> "micro-mode"? I say no.
Did you have a thought here? It may be we're arguing only about the
"destructuring parameter bans duplicate parameters" special case.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
On Sat, Dec 29, 2012 at 5:16 PM, Brendan Eich wrote: > I'm prepared to give up on the ban of duplicate formals when destructuring > parameters are present, if that will get rid of your objection to > "micro-modes". I don't recall anything else like this case. We arrived at it > mainly to simplify implementation in SpiderMonkey, but again: users do not > notice because no one uses duplicate formals. > >>> Are arrow functions, syntax and definite semantics, a "micro-mode"? If >>> not, >>> why not? I suspect you are using a mental desugaring spec but there's no >>> such spec. Allen has to deal with whether arrows have [[Construct]] (we >>> decided no, because |this| is bound to outer |this|). Is that a >>> "micro-mode"? I say no. > > Did you have a thought here? It may be we're arguing only about the > "destructuring parameter bans duplicate parameters" special case. If duplicate formals are the only such case, then I agree that the fear of micro-mode is a non-issue. Do we have an accurate record of the scoping of default value expressions? How about the interaction of head scope and top body scope? I recall there were problems here, but I'd need to review our decisions to see if they smell of more micro-modes. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich wrote:
Mark S. Miller wrote:
2) Make a micro-mode, adding yet additional mode switching in order to
supposedly avoid the complexity of dealing with one mode switch.
No, you are using micro-mode as an epithet without actually defining it in a
meaningfully different way from "new semantics for new syntax".
If I have a function
function foo(w, x, y) {
var [a, b] = y;
// use of a,b but not y in rest of body
}
and I change it to
function foo(w, x, [a, b]) {
// use of a,b but not y in rest of body
}
I have preserved its meaning. The change seems local to the individual
parameter. But if I have a function
function foo(x, x, y) {
Yes, but let me interject: no one does this. It's insane. A latent bug
or a quirk that deserves an early error.
var [a, b] = y;
// use of a,b but not y in rest of body
}
and I change it to
function foo(x, x, [a, b]) {
// use of a,b but not y in rest of body
}
now my second function is rejected.
Yes, with an early error.
Since no one does duplicate formal parameter in practice, this early
error is a good thing (tm).
This demonstrates the
"mode-nature" if you will of this rule.
Rather, new syntax gets new semantics.
We've shipped this for years in SpiderMonkey. I believe Rhino matches.
No one uses duplicate formals, so no one has ever complained.
The rejection must be
explained by a function-wide change of what the language accepts,
No, not function-wide! Purely function-head, more specifically the
parameter list.
even
though I changed only one parameter.
Parameter changes in ES6 have effects on the list. We don't allow more
than one rest parameter at the end, for example. Given
function f(a, b, ...r) {...}
If I try adding another ellipsis:
function f(a, ...b, ...r) {...}
I get an early error. Another good thing(tm), and no less local than
destructuring parameters banning duplicate params.
OTOH, if destructuring is accepted only in strict code, then the
rejection of destructuring is explained only by strictness rules.
"rejection of duplicate parameters"
Yes, that's the way to explain it via (1). And you are right that the
condition for rejection of duplicate formals becomes more than "in
strict code". It has to be "in strict mode || destructuring present in
parameter list".
However, since duplicate formals are a do-not-want, always-a-bug,
freakish rarity bestowed on ES1 during standardization, this extra
disjunct is a spec-internal complexity, not anything users must worry about.
I'm prepared to give up on the ban of duplicate formals when
destructuring parameters are present, if that will get rid of your
objection to "micro-modes". I don't recall anything else like this case.
We arrived at it mainly to simplify implementation in SpiderMonkey, but
again: users do not notice because no one uses duplicate formals.
Are arrow functions, syntax and definite semantics, a "micro-mode"? If not,
why not? I suspect you are using a mental desugaring spec but there's no
such spec. Allen has to deal with whether arrows have [[Construct]] (we
decided no, because |this| is bound to outer |this|). Is that a
"micro-mode"? I say no.
Did you have a thought here? It may be we're arguing only about the
"destructuring parameter bans duplicate parameters" special case.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Put everything new in ES6 as implicit opt-in for strict mode? It certainly
is the simplest of all options, both for implementors and users. It also
removes the "big enough carrot" problem. Any individual feature may not be
enough of a carrot to sway a user, and taken as one by one choice, might
leave room for devs to pick and choose around strict mode (if there ends up
being some perceived difficulty or annoyance factor). But I can't imagine
anyone opting out of everything ES6 provides just to avoid strict mode. The
only reason people are likely to avoid everything in ES6 is compat concerns
which is orthaganol to strict mode.
Or something like require all ES6 features be inside modules, which
accomplishes the same thing. I know I saw this discussion before, or
something like it, but wasn't able to locate it.
On Saturday, December 29, 2012, Kevin Smith wrote:
> I gotta say, I'm in agreement with Mark (and even Andreas) here. 1JS,
> under all modes just isn't going to work (let[x] = y proves that). And
> keeping track of what's allowed under which mode (and why) could get
> complicated and difficult to explain.
>
> But what about this?
>
> One JS,
> Under strict mode,
> With awesome for all?
>
> Sounds good to me!
>
> { Kevin }
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
I gotta say, I'm in agreement with Mark (and even Andreas) here. 1JS,
under all modes just isn't going to work (let[x] = y proves that). And
keeping track of what's allowed under which mode (and why) could get
complicated and difficult to explain.
But what about this?
One JS,
Under strict mode,
With awesome for all?
Sounds good to me!
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module
Hi,
I did a thorough revision of Allen's Rev12 and Rev13 drafts which
incorporate (among many other things) the refactored MOP, symbols, proxies
and the Reflect module in the ES6 draft.
Below is a long list of detailed comments, both editorial and more
substantial in nature.
It's too cumbersome for me to file bugs for every individual comment.
Allen, please let me know what comments are worth filing a bug for.
Before delving into the details, two more things:
First, thank you Allen for the great spec work. Overall I'm very happy with
the way proxies have been incorporated into the ES6 draft.
Second, if people want to comment on a particular issue, I suggest to
rename the topic and fork off a separate thread. That will be more
manageable, and will allow people that don't want to read through this
whole list to follow the separate discussions.
Cheers,
Tom
== Comments based on ES6 draft Rev. 13 (21 dec. 2012) ==
=== General remarks ===
* [[GetP]]/[[SetP]] => rename these to just [[Get]] and [[Set]]?
* [[GetInheritance]]/[[SetInheritance]] => why not
[[GetProto]]/[[SetProto]]?
- More familiar to ECMAScript programmers
- No risk of confusion with function "prototype" property
- For ordinary objects, [[GetInheritance]] returns the value of the
[[Prototype]] field
* [[SetInheritance]]/Reflect.setPrototypeOf: I'm not sure this was agreed
upon. Especially since __proto__ is currently specified as a data property.
This means there is no setter that separately reifies the ability to set
the prototype. Thus, it's perfectly possible to just exclude
[[SetInheritance]] and Reflect.setPrototypeOf from the spec.
* I'm a bit uncomfortable with the removal of property descriptor
normalization in the getOwnPropertyDescriptor/defineProperty traps.
Especially for getOwnPropertyDescriptor I think it's a breaking change
w.r.t. ES5.1.
=== Chapter 8 ===
8.1.6.2
"Unless explicitly specified otherwise, internal data properties may be
dynamically added to ECMAScript objects."
Isn't it safer to err on the side of safety and specify the opposite? (i.e.
"properties cannot be dynamically added unless specified otherwise")?
Table 8:
* [[PreventExtensions]] internal method: should return a Boolean success
value
* [[Delete]]: I would remove "because its [[Configurable]] attribute is
false." from the description. Proxies and host objects may return false for
other reasons as well (cf. the recent discussions about DontDelete vs.
configurable:false)
* [[Enumerate]]: typo: "Returns an iterator object that {iterates} over
the string values"
* [[Keys]] should be removed
* [[HasProperty]] should probably be added to this table again
* [[OwnPropertyKeys]]: the return type should be changed to Object
(iterator)
8.3.4 Object [[PreventExtensions]]()
This method should return a Boolean (true).
8.3.7.3 ValidateAndApplyPropertyDescriptor
Typo: "… and no{t} object updates are {pre}formed"
The note: "However, if O has an [[BuiltinBrand]] internal data property
whose value is BuiltinArray O also has a more elaborate
[[DefineOwnProperty]] internal method defined in 15.4.5.1." is probably
more appropriately placed at the top of section 8.3.7 (closer to the
definition of [[DefineOwnProperty]])
The note: "NOTE Step 10.b allows any field…" should probably refer to Step
10.a (there is no longer a step 10.b in the new
ValidateAndApplyPropertyDescriptor algorithm)
8.7.8 Object [[HasProperty]] ( P )
- The section number should probably be 8.3.8
"When the [[GetProperty]] internal method" => should probably be
[[HasProperty]].
8.3.19 Ordinary Function Objects
Table 13: Description for [[Home]]
"…this is the object whose [[Inheritance]] provides the object…"
should probably be [[GetInheritance]].
8.4 Built-in Exotic Object Internal Methods and Data Fields
A few typos in introductory text:
"This specification define{s} several kinds of built-in exotic objects.
These objects generally behave similar to ordinary objects except for a
few specific situ{t}ations. The following exotic objects use the ordinary
object internal methods except where it is explicitly specified {other}wise
below:"
8.4.4 Exotic Symbol Objects
Typo: "A{n} Symbol object is an exotic object…"
"Exotic String objects have {the} a..."
In the introduction, it's mentioned that "Symbol exotic objects are unique
in that they are always immutable and never observably reference any other
object."
Yet, as currently specified, evaluating aSymbol.toString yields a reference
to the global Object.prototype.toString function (which is mutable by
default).
Shouldn't aSymbol.toString just be undefined?
I notice that Object.prototype.toString special-cases Symbols anyway, so
Object.prototype.toString.call(aSymbol) continues to work fine.
In case aSymbol.toString should continue to return
Object.prototype.toString, I would advise to modify [[HasProperty]] for
Symbols to answer 'true' for the string "toString", and [[Delete]] to
answer 'false', so that [[Get]],[[HasPrope
Re: excluding features from sloppy mode
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich wrote:
> Mark S. Miller wrote:
>>
>> On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich wrote:
>>>
>>> Who ever proposed that? It seems a misunderstanding. No one is saying
>>> that,
>>>
>>> e.g., destructuring formal parameters, or a rest parameter, should flip
>>> the
>>> containing function into strict mode. Banning duplicate formals in no
>>> wise
>>> does that.
>>
>>
>> This is an example of the micro-modes issue. If optional, rest, and/or
>> destructuring needs to enforce no duplicates, then we have two
>> choices:
>>
>> 1) Make these features available only in strict code, which doesn't
>> require any new special case -- since strict already bans duplicate
>> parameter names.
>
>
> Agree so far.
>
>
>> 2) Make a micro-mode, adding yet additional mode switching in order to
>> supposedly avoid the complexity of dealing with one mode switch.
>
>
> No, you are using micro-mode as an epithet without actually defining it in a
> meaningfully different way from "new semantics for new syntax".
If I have a function
function foo(w, x, y) {
var [a, b] = y;
// use of a,b but not y in rest of body
}
and I change it to
function foo(w, x, [a, b]) {
// use of a,b but not y in rest of body
}
I have preserved its meaning. The change seems local to the individual
parameter. But if I have a function
function foo(x, x, y) {
var [a, b] = y;
// use of a,b but not y in rest of body
}
and I change it to
function foo(x, x, [a, b]) {
// use of a,b but not y in rest of body
}
now my second function is rejected. This demonstrates the
"mode-nature" if you will of this rule. The rejection must be
explained by a function-wide change of what the language accepts, even
though I changed only one parameter.
OTOH, if destructuring is accepted only in strict code, then the
rejection of destructuring is explained only by strictness rules. In
strict code, the rejection of duplicate parameters is explained only
by strictness rules, and applies to both functions above. No
micro-modes in sight.
>
> Are arrow functions, syntax and definite semantics, a "micro-mode"? If not,
> why not? I suspect you are using a mental desugaring spec but there's no
> such spec. Allen has to deal with whether arrows have [[Construct]] (we
> decided no, because |this| is bound to outer |this|). Is that a
> "micro-mode"? I say no.
>
>
>> By our previous criteria, #1 is obviously simpler than #2.
>
>
> I dispute that. The complexity to count is user-facing, not spec-internal or
> mental-desugaring or other invisible complexity. Users need to know about
> arrows when writing them. When calling, not so much (one cannot assume all
> functions are constructors, even in ES1 [builtins]).
>
> Let's try to get to an apples-to-apples user-facing complexity metric, and
> leave the stuff under the spec hood out.
>
> /be
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Mark S. Miller wrote: On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich wrote: Who ever proposed that? It seems a misunderstanding. No one is saying that, e.g., destructuring formal parameters, or a rest parameter, should flip the containing function into strict mode. Banning duplicate formals in no wise does that. This is an example of the micro-modes issue. If optional, rest, and/or destructuring needs to enforce no duplicates, then we have two choices: 1) Make these features available only in strict code, which doesn't require any new special case -- since strict already bans duplicate parameter names. Agree so far. 2) Make a micro-mode, adding yet additional mode switching in order to supposedly avoid the complexity of dealing with one mode switch. No, you are using micro-mode as an epithet without actually defining it in a meaningfully different way from "new semantics for new syntax". Are arrow functions, syntax and definite semantics, a "micro-mode"? If not, why not? I suspect you are using a mental desugaring spec but there's no such spec. Allen has to deal with whether arrows have [[Construct]] (we decided no, because |this| is bound to outer |this|). Is that a "micro-mode"? I say no. By our previous criteria, #1 is obviously simpler than #2. I dispute that. The complexity to count is user-facing, not spec-internal or mental-desugaring or other invisible complexity. Users need to know about arrows when writing them. When calling, not so much (one cannot assume all functions are constructors, even in ES1 [builtins]). Let's try to get to an apples-to-apples user-facing complexity metric, and leave the stuff under the spec hood out. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich wrote: > Andreas Rossberg wrote: >> >> I haven't replied to this thread yet, because I feel that I already >> made all the same arguments repeatedly to no avail. ;) However, let >> me reiterate one particular observation, which is that IMHO much of >> the discussion (and decision making) around 1JS, modes, and opt-ins is >> just mistargeted. > > > Could be, let's see. > > >> Namely, it is primarily based on the expectations and needs of >> _current_ users. Users that are aware of what's ES3 or 5 and who are >> about to investigate what's new in ES6. To those users, design choices >> like making new constructs opt into strict mode by default will not >> seem a big deal, even natural. > > > Glad to hear some concurrence. > > >> But that group will be irrelevant after a relatively short time of >> transition! > > > Who knows? "Relatively short time" will be measured in units of years, > though. > > >> ES6+ will stay much longer (at least that's what we are working for). >> Consequently, what should take precedence are the expectations and >> needs of _future_ users of ES. Those who will come to ES6+ without >> knowing nor caring about the colorful history of its earlier versions. >> For them, having various features locally change the semantics of >> unrelated constructs > > > Whoa. > > Who ever proposed that? It seems a misunderstanding. No one is saying that, > e.g., destructuring formal parameters, or a rest parameter, should flip the > containing function into strict mode. Banning duplicate formals in no wise > does that. This is an example of the micro-modes issue. If optional, rest, and/or destructuring needs to enforce no duplicates, then we have two choices: 1) Make these features available only in strict code, which doesn't require any new special case -- since strict already bans duplicate parameter names. 2) Make a micro-mode, adding yet additional mode switching in order to supposedly avoid the complexity of dealing with one mode switch. By our previous criteria, #1 is obviously simpler than #2. > > So what exactly are you referring to here, in the way of a live proposal? > > /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Brendan Eich wrote: subtle mode mixtures, I don't buy this one either. We have ES5 sloppy and strict, they mix only statically, with well-defined rules based on "use strict"; (which is not a readability trump card to throw, as discussed). Any dynamic mixing is at the function call boundary. Now, consider modules, classes, generators, and arrows: * modules export functions, which are strict by definition under 1JS as elaborated. * classes define prototype methods (possibly static methods in future) and possibly a constructor. * generator functions are a kind of function. * arrows are a kind of function. In all these cases, we have static source delimiting, no mode mixing. In all these cases, we have functions as the smallest units of abstraction. These already may be strict or sloppy per ES5, at runtime. Furthermore, all four bullets need definite semantics in ES6. We have to say what poison pill properties, what rules for duplicate formals, etc. are. There could be some "spec reuse" argument for factoring such that strict mode decides these things, but with novel syntax in play, that is not an overriding argument against strict-by-fiat. Allen has already started spec'ing some of these things. He should weigh in on the "spec reuse" situation, but my point here is that strict-by-fiat-for-novel-bodies as I advocate does not create new "subtle mode mixtures". Yes, one won't see "use strict"; at the front of function bodies in these four bulleted cases. So what? One often has to hunt thousands of lines up, and match braces of module-pattern IIFEs, to know whether a given function is in strict mode anyway. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Andreas Rossberg wrote: On 29 December 2012 14:51, Axel Rauschmayer wrote: I’m sympathetic to both sides of this argument. How would you handle things? Ideally? Backing out of the whole 1JS marketing maneuver? It's not just marketing surface, but lack of version= substance. How do you propose backing out of that? Defining RFC4329 application/javascript and application/ecmascript ;version= parameter values and telling people to write script tags using those types? In the long run, I see it as more harmful than helpful, as it inevitably leads to complexity creep, subtle mode mixtures, Note the V8 team (via MarkM) rightly prefigured 1JS by asking for "no more modes" several years ago. Now you want explicit modes? The world turns... and refactoring hazards that are there to stay for eternity. Instead, just make all new features strict-mode only and be done with it. Let's be clear about the refactoring hazards. They do not involve early errors. So the only issues are the runtime semantic changes: * The arguments object in a strict function not aliasing formal parameters. * Poison pill properties on strict function objects. * Anything else I'm forgetting. Is this really that bad in the way of refactoring hazards? Anyone refactoring from old to ES6 or later code should get rid of arguments. The poison pill properties may be needed so that means don't refactor this function, leave it in sloppy mode using function syntax. What's the big hazard I'm missing? But I've accepted that I am in the minority with that opinion, and it's too late anyway. Short of that, at least hold the line with modules as the only implicit opt-in. There's a case for class bodies as implicitly strict, you can't dismiss it with generalities about refactoring hazards in my book :-P. Care to deal with the specific pro-strict-class argument? But in reality I'm pretty sure that we will give in to extending the list at some point, if not in ES6 then in ES7. I say all new forms with distinct heads and code-bearing bodies should be strict-only. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
Andreas Rossberg wrote: I haven't replied to this thread yet, because I feel that I already made all the same arguments repeatedly to no avail. ;) However, let me reiterate one particular observation, which is that IMHO much of the discussion (and decision making) around 1JS, modes, and opt-ins is just mistargeted. Could be, let's see. Namely, it is primarily based on the expectations and needs of _current_ users. Users that are aware of what's ES3 or 5 and who are about to investigate what's new in ES6. To those users, design choices like making new constructs opt into strict mode by default will not seem a big deal, even natural. Glad to hear some concurrence. But that group will be irrelevant after a relatively short time of transition! Who knows? "Relatively short time" will be measured in units of years, though. ES6+ will stay much longer (at least that's what we are working for). Consequently, what should take precedence are the expectations and needs of _future_ users of ES. Those who will come to ES6+ without knowing nor caring about the colorful history of its earlier versions. For them, having various features locally change the semantics of unrelated constructs Whoa. Who ever proposed that? It seems a misunderstanding. No one is saying that, e.g., destructuring formal parameters, or a rest parameter, should flip the containing function into strict mode. Banning duplicate formals in no wise does that. So what exactly are you referring to here, in the way of a live proposal? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL attribute reflection
David Bruant wrote: Boris, what initially triggered my questioning of the inherited accessor setting is in this message: https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html Mostly concerns about a mix of API "securability" and convenience. I "demonstrate" that if every attribute is an inherited accessor, then, it's possible to secure the environment, but it can be at the expense of API usability up to asking people to tweak their code (which is an anti-goal when trying to secure your code from, say, an advertiser's code) Can you give an example? Ads loaded via cross-site script src= need defense at a lower depth, without any code changes, by giving them a distinct trust label from the including page's label. I proposed this at AppSecUSA (while jetlagged from travel from London through Austin to NYC on the eve of Hurricane Sandy :-P). More to say when there is time, but the idea is to let the VM distinguish ad code from page code and let CSP enforce finer-grained policies via membranes (in-process, no inversion of control flow -- see Alex Russell's question if the Q&A made the video). Le 28/12/2012 22:18, Boris Zbarsky a écrit : On 12/28/12 12:31 PM, Boris Zbarsky wrote: When we have gets through a proxy down in the 20-30 cycle range on modern hardware, I'm happy to talk about proxies performance-wise. ;) One other note. I'm somewhat sympathetic to the argument that the spec could describe things as proxies while actual implementations then implement them however the heck they want under the hood. I was half-clumpsy (I mentioned "An ES6 proxy-based implementation" by mistake), but it was what I was asking for. That's what I tried to express when I wrote "Using ES6 proxies semantics to explain own data properties in WebIDL would..." From the beginning, I wanted to have a spec/semantics discussion. Implementations are free to do whatever they want as long as the observable behavior is conformant. That's all true of any spec: semantics deal in observables, all else is open to radical re-implementation and optimization. If I understand the rest of your post, you propose that WebIDL-based DOM specs could use a direct proxy with a certain handler sub-spec, unobservably, to create the same observable semantics that native C++ DOM implementations present? That is interesting. We'd need to work out the details. Go! ;-) /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL attribute reflection
Boris, what initially triggered my questioning of the inherited accessor setting is in this message: https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html Mostly concerns about a mix of API "securability" and convenience. I "demonstrate" that if every attribute is an inherited accessor, then, it's possible to secure the environment, but it can be at the expense of API usability up to asking people to tweak their code (which is an anti-goal when trying to secure your code from, say, an advertiser's code) Le 28/12/2012 22:18, Boris Zbarsky a écrit : On 12/28/12 12:31 PM, Boris Zbarsky wrote: When we have gets through a proxy down in the 20-30 cycle range on modern hardware, I'm happy to talk about proxies performance-wise. ;) One other note. I'm somewhat sympathetic to the argument that the spec could describe things as proxies while actual implementations then implement them however the heck they want under the hood. I was half-clumpsy (I mentioned "An ES6 proxy-based implementation" by mistake), but it was what I was asking for. That's what I tried to express when I wrote "Using ES6 proxies semantics to explain own data properties in WebIDL would..." From the beginning, I wanted to have a spec/semantics discussion. Implementations are free to do whatever they want as long as the observable behavior is conformant. WebIDL tries to close the gap between DOM semantics and ECMAScript semantics. In an ES5 world, the only thing that can explain the magic behavior is getters/setters (own or inherited). In an ES6 world, proxies can be an explanation too. For some cases like WindowProxy or NodeList, there will be no other way than using proxies to specify these objects in an ECMAScript replicable semantics. But that does involve each implementation then going through and creating yet another kind of thing internally which is not a proxy so it can be optimized sanely but still has some sort of behavior that isn't describable by normal getters/setters or normal value properties, so it's actually more implementation complexity than what WebIDL has right now, as far as I can tell. I'm not sure I'm convinced by "it's more work than right now". If you had told me that there is a fundamental issue that implementors can't work around when exposing own data properties, I would have backed out, but you suggested than it's possible to create "yet another kind of thing internally which is not a proxy so it can be optimized sanely". Is there some sort of way to use the getter/setter based implementation, but expose things as data property when asked via Object.getOwnPropertyDescriptor? And possibly more specification complexity too. For example, right now WebIDL doesn't have to define what happens when you try to delete DOM properties, because it's obvious, but once you try to use a proxy you have to define that sort of thing. Not with the direct proxy design. I think that the role of a spec using ES6 proxies as a spec tool would only be to define the different traps. Just say "there is no delete trap" and what happens when you try to delete becomes as obvious as how things are currently. Repeat with "keys", "getOwnPropertyNames" and most traps actually. One only needs to define the get/getOwnPropertyDescriptor and set/defineProperty traps which is the work that the spec is already doing at different places. I don't feel it would add complexity; it would just be different. Out of curiosity, do you have an idea of how much cost the |this| check? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
On 29 December 2012 14:51, Axel Rauschmayer wrote: > I’m sympathetic to both sides of this argument. How would you handle things? Ideally? Backing out of the whole 1JS marketing maneuver? In the long run, I see it as more harmful than helpful, as it inevitably leads to complexity creep, subtle mode mixtures, and refactoring hazards that are there to stay for eternity. Instead, just make all new features strict-mode only and be done with it. But I've accepted that I am in the minority with that opinion, and it's too late anyway. Short of that, at least hold the line with modules as the only implicit opt-in. But in reality I'm pretty sure that we will give in to extending the list at some point, if not in ES6 then in ES7. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
I’m sympathetic to both sides of this argument. How would you handle things? On Dec 29, 2012, at 14:47 , Andreas Rossberg wrote: > I haven't replied to this thread yet, because I feel that I already > made all the same arguments repeatedly to no avail. ;) However, let > me reiterate one particular observation, which is that IMHO much of > the discussion (and decision making) around 1JS, modes, and opt-ins is > just mistargeted. > > Namely, it is primarily based on the expectations and needs of > _current_ users. Users that are aware of what's ES3 or 5 and who are > about to investigate what's new in ES6. To those users, design choices > like making new constructs opt into strict mode by default will not > seem a big deal, even natural. > > But that group will be irrelevant after a relatively short time of transition! > > ES6+ will stay much longer (at least that's what we are working for). > Consequently, what should take precedence are the expectations and > needs of _future_ users of ES. Those who will come to ES6+ without > knowing nor caring about the colorful history of its earlier versions. > For them, having various features locally change the semantics of > unrelated constructs will be surprising at best. It means having to > remember a seemingly random set of rules for what semantics is active > where. > > The more such rules there are, and the more fine-grained they are, the > less readable code becomes, and the more error-prone programming and, > particularly, refactoring will be -- not just for the current > generation of ES programmers, but for all generations to come. IMHO, > that is the wrong trade-off entirely. > > /Andreas > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
I haven't replied to this thread yet, because I feel that I already made all the same arguments repeatedly to no avail. ;) However, let me reiterate one particular observation, which is that IMHO much of the discussion (and decision making) around 1JS, modes, and opt-ins is just mistargeted. Namely, it is primarily based on the expectations and needs of _current_ users. Users that are aware of what's ES3 or 5 and who are about to investigate what's new in ES6. To those users, design choices like making new constructs opt into strict mode by default will not seem a big deal, even natural. But that group will be irrelevant after a relatively short time of transition! ES6+ will stay much longer (at least that's what we are working for). Consequently, what should take precedence are the expectations and needs of _future_ users of ES. Those who will come to ES6+ without knowing nor caring about the colorful history of its earlier versions. For them, having various features locally change the semantics of unrelated constructs will be surprising at best. It means having to remember a seemingly random set of rules for what semantics is active where. The more such rules there are, and the more fine-grained they are, the less readable code becomes, and the more error-prone programming and, particularly, refactoring will be -- not just for the current generation of ES programmers, but for all generations to come. IMHO, that is the wrong trade-off entirely. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On dropping @names
On 28 December 2012 20:53, David Herman wrote: > On Dec 28, 2012, at 11:47 AM, Andreas Rossberg wrote: >> That seems clean, useful, consistent, and fairly easy to understand. >> Introducing extra rules for 'let'? Not so much. > > But TDZ does introduce extra rules! Especially with disallowing assignment > temporally before initialization. I have to disagree, see my other reply. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: barrier dimension, default dimension
On 28 December 2012 20:30, David Herman wrote:
>
> Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option?
> The bug that motivates all the arguments you've made is
> read-before-initialization, not write-before-initialization.
I agree that that would be a less error-prone semantics, but other
arguments still apply. IMO it's inferior to "TDZ-UBI-UNDEF" (the
current draft semantics) for three reasons:
1. Complexity/consistency
2. Readability
3. Future-proofness
Regarding (1), consider how to formulate the rules for "unhoisted"
bindings. Informally, "TDZ-UBI-UNDEF" says:
* Accessing a variable before its declaration has been executed is an
error. Furthermore, "let x" is shorthand for "let x = undefined".
The corresponding text for "TDZ-RBA-UNDEF":
* For immutable bindings, accessing a variable before its declaration
has been executed is an error. For mutable bindings, read-accessing a
variable before an assignment to it has been executed is an error.
Furthermore, "let x = e" is shorthand for "let x; x = e". A
let-declaration without a r.h.s. is a conditional assignment of
"undefined" that is performed if and only if no other assignment to
the declared variable has been performed before.
This is clearly less consistent and more complicated, for two reasons.
First, the definition has to be different for mutable and immutable
bindings (there is no such thing as an "assignment" to an immutable
binding). But even ignoring immutable bindings altogether, the
semantics for mutable ones alone are more complicated because of the
runtime case distinction you need to make for the conditional
initialization.
Regarding (2), let me repeat my mantra: reading is 10x more important
than writing. Now consider reading a piece of code like this:
{
// lots of stuff
let x;
// more stuff
print(x);
}
With the current rule, all you need to read to understand what is
printed for 'x' is the code between its declaration and its use. Any
code before the declaration cannot possibly matter, which arguably is
what one would expect intuitively (and what's the case in every other
comparable language with proper lexical scoping). Not so with the
TDZ-RBA-UNDEF rule, where understanding whether the variable is
assigned, and how, generally requires reading _all_ code in that block
up to its use.
Regarding (3), that has been argued before often enough, so I won't
repeat it here. Just let me note that future-proofness is not about
crossing a bridge early, as you seemed to suggest elsewhere, it's
about making sure that you haven't already burnt that bridge once you
get there.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
