that would be a more expected
behavior for ECMAScript, as for example Waldemar's last comment below points
out.
Luke
-Original Message-
From: Jason Orendorff [mailto:jason.orendo...@gmail.com]
Sent: Thursday, August 1, 2013 10:13 AM
To: Allen Wirfs-Brock
Cc: Luke Hoban; es-discuss
Subject
All current engines I could try return Number.prototype for:
12[__proto__]
But the new spec says this should be a TypeError.
It's more consistent with the other members of Object.prototype to do an
implicit ToObject here, and apparently matches existing implementations. Is it
intentional
All current engines I could try return Number.prototype for:
12[__proto__]
But the new spec says this should be a TypeError.
What is the relevant part of the new spec?
In B.2.2.1, step #2 throws a TypeError instead of doing a ToObject.
get Object.prototype.__proto__
The value of
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Tuesday, July 16, 2013 7:02 PM
To: Luke Hoban
Cc: es-discuss
Subject: Re: 12[__proto__]
On Jul 16, 2013, at 6:33 PM, Luke Hoban wrote:
All current engines I could try return Number.prototype for:
12[__proto__]
But the new spec says
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote:
Two questions on new Number APIs:
1) Is it intentional that clz is on Number.prototype instead of Number? Why?
I think there is a stronger case to me made for Math.clz(number
Two questions on new Number APIs:
1) Is it intentional that clz is on Number.prototype instead of Number? Why?
2) Is it intentional that Number.toInteger(Infinity) returns true?
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
From: es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] On Behalf Of Erik Arvidsson
Yeah, these test all look incorrect to me. IE11 implements an older draft
where __proto__ was a magic property.
That’s right. Our implementation predates the May spec updates that
Andreas Rossberg wrote:
On 13 June 2013 23:40, Brendan Eichbren...@mozilla.com wrote:
I think V8 has a de-facto bug to fix. I'm ok with requiring stability
as a normative property of Array.prototype.sort given such a V8 bugfix.
IIUC, current IE versions are not been stable either, so
The ES6 draft grammar no longer allows the following, which was legal ES5:
for(var i = 1 in []) {}
Was that an intentional breaking change? If so, why? (Of course, there are
exceedingly limited practical uses of this, but that alone doesn't seem to
justify a breaking change).
Luke
From: Erik Arvidsson [mailto:erik.arvids...@gmail.com]
This was from back in the days when Google code search was still available
and the only hits we found were from test suites.
On Jun 13, 2013 8:54 PM, Brendan Eich bren...@mozilla.com wrote:
We had some web crawling help, IIRC. We also
Can the slides from the last TC39 meeting be downloaded somewhere? From
Rick's notes, they looked interesting.
Sure thing - I've posted the slides here: http://sdrv.ms/W21q9e. These
slides were talking points, Rick's notes contain the broader discussion at the
meeting here:
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of John-David Dalton
Subject: Number.isNaN
I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it
make sense to instead check that the [[BuiltinBrand]] is
BuiltinNumberWrapper
From: Mark S. Miller [mailto:erig...@google.com]
In that case, the current spec is wrong. The purpose of introducing
Number.isNaN is to repair the following bug in the global isNaN:
isNaN(foo) // returns true
Indeed, as Yusuke noted on the other reply, I referred to the wrong
Brendan Eich wrote:
Hard to say what IE8's share will be, but IE9 did not implement strict mode
IIRC. IE10 did.
Michał Z. Gołębiowski wrote:
IE10 sort of did. The following code:
(function(){ 'use strict'; return !this; })();
returns false in IE10. Who knows what other
deviations from the
From: Patrick Mueller
On Wed, Oct 17, 2012 at 5:04 PM, Russell Leggett russell.legg...@gmail.com
wrote:
module a.js {
import b from b.js;
console.log(a);
export let a = a;
}
module b.js {
console.log(b);
export let b = b;
}
From: Andreas Rossberg [mailto:rossb...@google.com]
On 17 September 2012 03:35, Luke Hoban lu...@microsoft.com wrote:
__Temporal dead zones__
As an experiment, I took the early-boyer test from V8 and changed 'var' to
'let'. In Chrome preview builds with 'let' support, I saw
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
On Sep 16, 2012, at 9:35 PM, Luke Hoban wrote:
As an experiment, I took the early-boyer test from V8 and changed 'var' to
'let'. In Chrome preview builds with 'let' support, I saw a consistent ~27%
slowdown. That is, the 'let
From: Brendan Eich [mailto:bren...@mozilla.org]
Allen Wirfs-Brock wrote:
As stated above, let isn't the motivator for TDZ, it's const. Let could
easily be redefined to not need a TDZ (if that really proved to be a major
area of concern). So, you either need to argument against const
We've begun deeper investigations of implementation practicalities related to
let/const, and two significant performance concerns have been raised. I think
these both merit re-opening discussion of two aspects of the let/const design.
__Temporal dead zones__
For reference on previous
Hi, I'm writing a library for ES5 to add module system like ES6, I just want
to confirm some behaviors of ES6 module system:
module A {
export var a = 'a'
export function changeA(v) {
a = v
}
}
module B {
import * from A
console.log(a) // 'a'
changeA('a1')
What is the intended behavior of this code:
(function() {
eval(const x = 4);
const x = 3;
})();
The ES6 draft spec seems to be missing a few of the details that would
contribute to answering this. Specifically, section 15.1.2.1 on eval refers to
10.4.2, which no longer
Two questions on maximally minimal classes.
1) Should a super constructor call be made if no derived constructor is
specified?
The wiki and spec drafts suggest that no super call is made automatically on
behalf of the developer if they leave off a constructor declaration in a
derived class.
On Tuesday, July 3, 2012 11:42 AM, Allen Wirfs-Brock wrote:
On Jul 3, 2012, at 9:07 AM, Brendan Eich wrote:
Causality was the other way, of course: I implemented splice in SpiderMonkey
in 1997 based on Perl 4:
http://perldoc.perl.org/functions/splice.html
and indeed it handles
In fact, without |, are there any cases where super behaves correctly in
an object literal, other than making super calls to Object.prototype
functions?
We haven't eliminated the ability to define object literals that inherit from
objects other than Object.prototype. We have just
On May 31, 2012, at 1:54 PM, Allen Wirfs-Brock wrote:
On May 31, 2012, at 1:53 AM, Herby Vojčík wrote:
Hello,
reacting to super only in classes, I'd like to propose widening it just a
little bit:
1. Allow super in every concise methods (in classes, as well as out of them).
Basically
In the discussion of max/min classes at the March TC39 meeting, there was
support for minimal class syntax, but a couple concerns with max/min classes in
particular.
One category of concern is the (intentional) bare-bones nature of max/min. In
this case though, I think it has been
On May 22, 2012, at 9:29 AM, Erik Arvidsson wrote:
I think this proposal has one fatal flaw and that was what brought it
down the last time we had a proposal which used the same concepts.
Given:
class C(x) {
public method() {
return x;
}
}
It seems like the arguments to the
Herby Vojčík he...@mailbox.sk wrote:
I just don't understand why you use class keyword here. This will work
without any changes, as-is, with plain function keyword. After all, you just
augment a constructor definition.
The body of this kind of function is different, in that it can define
It looks like methods on the prototype can access constructor arguments
when they can't. I worry that users would expect this to work:
class Rect(width, height) {
public area() { return width * height; }
}
Right - this is the concern that others raised on a parallel branch of the
So, FF (= 4??) and IE9 don't seem to support unicode escape based
de-keywordization and the web doesn't appear to have collapsed. That seems
like a good indication that this isn't a major interp. concern and we can
think about what we want such unicode escapes to mean rather than being
The wiki says that this should fill the array with 'undefined' (I believe
the spec draft aims to say the same, but I can't tell where this is
established).
The same runtime semantics routines are used for both default parameter
initialization and for initializing array destructurings in
On Fri, Mar 30, 2012 at 3:25 PM, James Burke jrbu...@gmail.com wrote:
[snip]
The module_loaders API has a way to do a runtime module registration, but as
I understand it, it means that a consumer of my library then needs to then
use the System.load() API to get a hold of it.
My
Great to see the arrow syntax proposal moving forward.
I think I missed a step though in the reasoning for moving to this proposal vs.
the previous arrow proposal. What problem did the previous proposal have that
is addressed with the new proposal?
There's a couple concerns I have with
Great to see the arrow syntax proposal moving forward.
I think I missed a step though in the reasoning for moving to this
proposal vs. the previous arrow proposal. What problem did the previous
proposal have that is addressed with the new proposal?
The ambiguity between a block body and
I think fully TCP- compliant do expressions are pure win, FTR.
I second this, of course, based solely on the experience I had writing up
these examples:
https://gist.github.com/2013909
https://github.com/rwldrn/popcorn-js/compare/tri-lambda
Luke Hoban wrote:
The do expressions serve a separate purpose of changing the meaning of
return (but not break and continue)
Dave proposed at
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021000.html
that do expressions be fully TCP compliant. No way to be half-pregnant
But my primary point was just that in Rick's examples, there doesn't
appear to be any reliance on TCP at all. Had = supported blocks on the
RHS as in the original arrow proposal, all the code samples would be
simpler, simply removing the 'do'. I believe this will generally be true
too.
Brendan Eich wrote:
Kevin's analysis contradicts your assertion. Expression-bodied
functions with bound |this| (or var self=this outside) predominate in
the code he surveyed.
See thread headed by this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021126.html
Yeah
The bracket syntax is pretty confusing with object literal notation imo.
It shouldn't be too confusing, and the similarity is in fact intentional.
You should read import as destructuring (and export as the inverse
structuring, if you want).
I agree that this isn't really a question
Dave -
Great to see the updates. A couple of questions:
import foo.js as Foo;
import foo from foo.js;
These two forms look rather confusingly similar given how different they are,
and the inversion of order of where the filename lives doesn't seem to line up
with the semantic difference
Section 15.8.2.28 in es6libraryextensions.pdf describes the result of
Math.hypot as NaN if x or y is NaN.
I believe IEEE754 defines hypot of Infinity with anything (even NaN) as
Infinity, thus:
hypot(Infinity,NaN) == hypot(NaN,-Infinity) == Infinity
Thanks - I've fixed this in the working
So I suggest adding a Math.hypot2 as well.
+1
Agreed, I've added hypot2 to the proposal as well as making both hypot and
hypot2 variadic.
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Usually hypot is implemented something like |x| * sqrt(1 + (y / x)^2) (|x|
|y|) instead, but such a formula for a variadic hypot is probably
non-trivial.
I believe, as Roger noted on another branch, the variadic version of this
formula just divides all arguments by the maximum of the
Although not specified in ES5, octal escapes are required in regular
expressions for web reality [1,2]. [1] even claims the extensions are
extensive and consistent across browsers. But for invalid octal escapes,
the browsers are not consistent. For example:
/^\8$/ matches \\8 in
Hi Roger -
Replying to the four proposals you sent in one mail for easier discussion:
*** Make Math.hypot(x,y,z,...) variadic ***
This sounds like a reasonable extension. Oddly, I haven't seen any other
libraries support a variadic hypot function, but the use cases seem obvious
enough.
I raised some concerns about the current ES5.1 spec rules for daylight savings
handling (15.9.1.8) with a few folks at recent TC39 f2f meetings. Norbert also
raise similar concerns in reviewing issues related to globalization APIs, and
in notes on internationalization issues with ES5 spec
What do you think? Do you like - better than | ? Is it ok to not have it
available for some possible future function shorthand?
Both = and - have strong associations with function shorthands from C#,
Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more. Whether or not
JavaScript
What do you think? Do you like - better than | ? Is it ok to not have
it available for some possible future function shorthand?
Both = and - have strong associations with function shorthands from C#,
Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more. Whether or
not
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Peter Michaux
On Thu, Feb 23, 2012 at 12:35 PM, Mark S. Miller erig...@google.com
wrote:
if (arr.contains(foo)) {
vs
if (arr.indexOf(foo) !== -1) {
The readability of the above two
My takeaway from this thread is that there is support for the proposed
__proto__ semantics on the wiki [1], with a few modifications/additions. Are
the following a correct summary of the deltas?
*** Accessor vs. Data property
Although there does not appear to be a direct security implication
JS REPLs tend to parse input as Program productions. Parsing {} + {} as a
block followed by a unary expression is correct according to ES5 grammar for
Program. IE behaves the same.
Luke
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Axel
One of the valuable use cases for quasis that we've discussed is multi-line
string literals. It was just pointed out to me that the current proposal page
mentions an open issue which calls into question multi-line string literals and
the exact semantics of them. This is in
Great summary of the goals, and I agree with the plea for starting with opting
into ES6 through one simple declaration on the top of a program (and nowhere
else). Otherwise it's ES5 unchanged.
#6 has other variants as well, such as copy/paste hazards and even subtler
concatenation hazards,
According to the current API on
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders along with an
assumption (not yet decided) that the system loader would be at Object.system,
you would want this for the example shown below:
var intl = Object.system.loaded['@globalization']
Jumping in late, and possibly repeating some already covered ground, but this
is clearly an important topic.
Looking at all the proposals on these threads, I have to throw support behind
Mark's proposal below, or a close variant of it as discussed below and in some
of the other branches (I
And further, all new functionality would need to be loaded via a module?
This is a strong yes, without qualification so far in my view. We intend
for built-in modules to be accessible to unversioned/pre-Harmony script via
the heap (Object.system.load...).
This is true for ES6, but the
And further, all new functionality would need to be loaded via a module?
This is a strong yes, without qualification so far in my view. We intend
for built-in modules to be accessible to unversioned/pre-Harmony script
via the heap (Object.system.load...).
This is true for ES6, but the
Speaking on behalf of real world web developers, the opposition to
Globalization is that it's unnecessarily long. This is a long standing
problem with APIs that are designed by people that don't have to use them
everyday.
Agreed - a shorter name would be better - but the alternative being
1) String.prototype.reverse(), as proposed, corrupts supplementary
characters.
It was agreed at the meeting yesterday that this concern is significant enough,
and reverse does not have sufficiently compelling use cases, so should not be
included.
2) String.prototype.toArray(), as
The Harmony proposals page contains several additions to the core String,
Number and Math libraries, adding some of the most commonly created and
requested helper operations to these libraries for ES6. I've uploaded to the
wiki a first draft of candidate spec text for these library additions:
document.querySelector('#my-element').{
style.{
'color': 'red',
'padding': '5px'
}.
textContent: 'Hello'
};
I don't think I've seen this form of the .{ syntax discussed before. Is an
expression being used as the LHS of an object literal property assignment?
What does foo.{
My interpretation of these spec sections:
(new bound) instanceof bound
= (new Bar()) instanceof bound // bind's Construct defers to the
targetFunction and ignores bound thisValue
= bound.[[HasInstance]](new Bar()) // meaning of instanceof
= Bar.[[HasInstance]](new Bar()) // bind's HasInstance
The idea is definitely to subsume typed arrays as completely as possible.
Great.
The idea is that all Types have a known size, and all Data instances are
allocated contiguously.
For example, if you could put unsized array types inside of struct types, it
wouldn't be clear how to
Object.extend(src, dest)
This is certainly closest to paving the cowpath. Either via a built-in module
exporting 'extend', or as you suggest, directly on Object. The Object.extend
route is a bit harder to analyze, but not fatally so for any capable static
analysis framework.
Either way
From discussions with some Microsoft dev teams, that could be a 3+ year
difference in adoption timeline.
If this is a give me the goods now argument, and the goods can be expressed
via functions, I'm with you.
If this is new syntax takes too long to be usable due to downrev browsers,
Well, I think I understand what you're getting at: there's a sense in
which generators don't add the ability to do something that's *absolutely
impossible* to express in ES5.
OTOH, generators make it possible to express something that otherwise --
in general -- requires a deep
I agree wholeheartedly with these. In fact, I'd go further on (2), and
say Anything that can be done declaratively can also be done
imperatively, using ES5 syntax.
Like most principles, I think these are reasonable to keep in mind but
not absolute. In particular, I see no sensible
If so, it seems safe to consider generators as sugar for producing objects
whose visible behavior could have been built independently. And
interoperation appears to work cleanly in both directions using these
objects.
You're talking about interoperation in the old script calls new generator
I agree wholeheartedly with these. In fact, I'd go further on (2), and say
Anything that can be done declaratively can also be done imperatively, using
ES5 syntax. ES.next will have two syntaxes running on a single runtime,
sharing objects across a shared heap. I think we should ensure that
I agree wholeheartedly with these. In fact, I'd go further on (2), and
say Anything that can be done declaratively can also be done
imperatively, using ES5 syntax.
The problem here is that some new syntax cannot be faked with old syntax,
namely function calls, without quoting code in
My read of the spec is that thi\u0073 is a ReservedWord and should not be
allowed as an Identifer. So the following part of the examples quoted below
should be an early error:
var thi\u0073 = 42;
The text in 7.6 seems to address this with:
All interpretations of identifiers within this
there are lots of ES.next features that let us do something that we could
not do at all previously (weak tables and refs are a good example). features
that enable new kinds of applications we couldn't previous build.
+1 on this point. There’s been a lot of discussion of syntactic sugar
2) The conventional JS pattern is to place methods on the prototype, not the
instance, and many felt that the main thing classes need to provide is a
syntax to make this traditional semantics easier to express.
This is the big one.
Class syntax with class parameters instead of explicit
The primary scenario is what some people call subclassing the various
built-in classes of objects that have special internal state and behavior.
The most important of these classes are Array, Function, and RegExp.
Programmer want to be able to create instances of these whose direct
At the March meeting Binary Data was promoted to a Harmony proposal, and it was
agreed that it would need to be further rationalized with existing Typed Arrays
in browsers, including at least being interoperable with ArrayBuffer. With
more reflection on this, I believe it is important that we
The Private Names strawman currently combines a new runtime capability (using
both strings and private names as keys in objects) with several new syntactic
constructs (private binding declarations, #.id). At the March meeting, I
recall there was some support for the idea of separating these
Yes, I agree that separating them out is a good idea. Allen and I have
been working on this lately, and I've signed up to present private names at the
upcoming face-to-face. Our thinking has been along similar lines to what you
describe here.
Dave
Great - I see the new
If there were a more usable library variant of Object.create instead, it seems
the new syntax here would not be as necessary.
Instead of:
var o = myProto | {
a: 0,
b: function () {}
}
You could do:
var o = Object.make(myProto, {
a: 0,
b: function () {}
})
Related to this: We noticed that because of the behavior below, the text
describing [[Configurable]] in Table 5 is not correct. It claims that
[[Configurable]]=false implies no properties other than Value can be modified.
Could this be added to the errata?
Luke
From:
79 matches
Mail list logo
