On Oct 3, 2012, at 12:40 PM, François REMY wrote:
> Indirect eval is something introduced for ES5 Strict only, I believe.
Nope. See 15.1.2.1.1, no reference to strict.
Here's a better example:
(function(t){ var x = 'foo'; t("x = 'bar'"); alert(x); })(eval)
The indirect eval does not mod
On Oct 3, 2012, at 10:05 AM, François REMY wrote:
> In non-strict ES, the “t” function may be eval, and eval could add a “oops”
> variable in the parent function getOoops.
I don't believe this is true. This does not constitute a direct call to eval
(15.1.2.1.1), and as such the eval will take
On Jun 15, 2012, at 12:33 PM, David Herman wrote:
> So I favor ?? as well as both ||= and ??=.
Adding ||= and ??= without &&= will cause my symmetry-reflex to twitch, despite
not seeing a purpose for it I may find it hard to resist supporting that too.
;-)
G.
On May 29, 2012, at 11:19 PM, Brendan Eich wrote:
>>> o.( a = "alpha", b = "beta" )
>>>
>>> v.
>>>
>>> o.( a = "alpha"; b = "beta" )
The similarity between .{ foo: bar } & .{ foo= bar } concerns me, it's too
footgunish. This I like.
cheers,
G.
___
e
On Mar 26, 2012, at 11:57 PM, Erik Corry wrote:
> Add /U to mean old-style regexp literals in Harmony code (analogous to
> /s and /S which have opposite meanings).
Are we sure this has enough utility to be worth adding? - it seems unlikely
that programmers are going to often have cause to explici
On Mar 26, 2012, at 2:13 PM, Erik Corry wrote:
> This is too nasty. The regexp constructor should not have to look up
> the stack to see what behaviour is expected of it.
I think you misunderstood me - I think we're saying the same thing. :-)
If we do imply the u flag for regexp literals in mod
Hi Norbert,
I really like the direction you're going in, but have one minor concern
relating to regular expressions.
In your proposal, you currently state:
"A code unit that is in the range 0xD800 to 0xDFFF, but is not part of
a surrogate pair, is interpreted as a code point with the sa
d anyway transport-encoding compression makes this moot.
>
> Anonymous classes are an important use case IMHO, to match anonymous
> functions and the prototypal pattern.
>
> /be
>
>
> Gavin Barraclough wrote:
>> On Mar 23, 2012, at 12:42 AM, Claus Reinke wrote:
>>
On Mar 23, 2012, at 12:42 AM, Claus Reinke wrote:
> - would it make sense to name the constructor after the class
> (avoiding 'constructor' and 'new')?
I was about to suggest exactly the same thing.
If I see a line of code saying
let x = new FooBar();
and want to understand what it does, I
On Mar 21, 2012, at 3:28 PM, David Herman wrote:
> * importing with renaming:
>
>import { draw: drawGun }from "cowboy.js",
> { draw: drawWidget } from "widgets.js";
Hey Dave,
This all looks really nice! - the only thing that threw me was the export
rename – I intuitively expe
Hi Bernd,
You're assuming that the descriptor is a generic descriptor - that isn't the
case (accessor descriptors don't have a writable property), see 8.10.2,
"IsDataDescriptor".
As such, we don't return from step 8 of 8.12.9, and instead reach step 10.a.i.
cheers,
G.
On Mar 19, 2012, at 11:5
I believe behaviour is defined by the fourth paragraph of chapter 15:
"Unless otherwise specified in the description of a particular function, if a
function or constructor described in this clause is given fewer arguments than
the function is specified to require, the function or constructor sha
On Mar 7, 2012, at 11:54 AM, Brendan Eich wrote:
> The obvious workaround: parenthesize. This is arguably small potatoes given
> parameter default values being new.
>
>> Using '|' to wrap arguments is problematic, given its existing usage within
>> the language. There is a real advantages to a
On Mar 7, 2012, at 8:35 AM, Rick Waldron wrote:
> Honestly, I'm starting to believe that most nay-sayers would get over
> block-lambda looking weird at first and learn to really love the benefit it
> provides. Sure they might say "it looks really bizarre", but they will also
> say "remember when
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
> Does it have to be grawlix? I proposed
>
> let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a clear
directionality in the operation (e.g. chasing a chain of pointers in C), but
the lack
On Feb 20, 2012, at 8:37 AM, Brendan Eich wrote:
> BRS makes 21-bit chars, so just as String.prototype.charCodeAt returns a code
> point, String.fromCharCode takes actual code point arguments.
>
> Again I'd reject (dynamically in the case of String.fromCharCode) any in
> [0xd800, 0xdfff]. Other
On Feb 19, 2012, at 10:05 PM, Allen Wirfs-Brock wrote:
>> Great post. I agree 3 is not good. I was thinking based on today's exchanges
>> that the BRS being set to "full Unicode" *could* mean that "\u" is
>> illegal and you *must* use "\u{...}" to write Unicode *code points* (not
>> code un
On Feb 19, 2012, at 3:13 PM, Allen Wirfs-Brock wrote:
>> My implementor's bias is showing, because I expect many engines would use
>> UTF-16 internally and have non-O(1) indexing for strings with the
>> contains-non-BMP-and-BRS-set-to-full-Unicode flag bit.
>
> A fine implementation, but not obs
Perhaps I am overly fatalistic here, but if we don't specify an iteration order
I think the web will just go and specify it for us, as it has for object
property iteration order. We can bet against history repeating itself if we
wish.
On Feb 14, 2012, at 7:13 PM, Brendan Eich wrote:
>> Mark Mi
On Feb 13, 2012, at 9:55 AM, Allen Wirfs-Brock wrote:
> Finally, an alternative to extending [[Get]] and [[Put]] would be to extend
> the GetValue abstraction operation (8.7.1) and the Simple Assignment
> evaluation semantics (11.13.1).
>
> [[DefineOwnProperty]] and [[Delete]] still need to be
On Feb 12, 2012, at 11:28 AM, Brendan Eich wrote:
> Heh, I knew that was coming. I'll amend to say "of long standing" after
> "implementations" :-P.
:-D
> I still have a gut feeling that someone is going to take advantage of the
> setter for bad purposes that will be harder to block than would
On Feb 10, 2012, at 11:55 AM, Brendan Eich wrote:
> "over-specifying", right? I am in favor of specifying __proto__ minimally in
> Annex B.
>> But, one thing I would like enshrined in the spec is that `"__proto__" in
>> Object.create(null) === false`.
> For sure!
The idea of a minimal specifica
On Feb 10, 2012, at 12:43 AM, David Bruant wrote:
> Maybe I'm missing something, but what you're proposing is *exactly* a
> frame-based check.
Hi David,
No, the proposed check does not correlate exactly to a frame-based check. For
example, an object created using Object.create(null) may be ass
On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote:
> I would expect Gavin's approach to ultimately be even worse than mine from a
> semantic analysis perspective. It expose (via
> Object.getOwnPropertyDescriptor) functions that have the ability to mutate
> any object's [[Prototype]] property
Hi Allen,
On Jan 29, 2012, at 4:25 PM, Allen Wirfs-Brock wrote:
> There are no rules that constrain [[Put]] in this manner you are suggesting.
Sorry, perhaps my comments were unclear. The observation I was intending to
highlight was only that the current behaviour of [[Put]] will be to call
[
On Jan 29, 2012, at 11:36 AM, Allen Wirfs-Brock wrote:
> Other standard properties that have accessor like characteristics but look
> like data properties:
>
> array element properties
> array length property
> string character element properties
> argument object elements
> the "caller" propert
On Jan 28, 2012, at 3:58 PM, Allen Wirfs-Brock wrote:
> Since most implementations already seem to have special mechanism for giving
> "magic" behavior to certain properties I would expect them to use some of
> those mechanisms here.
No - in JSC I'm pretty sure it's going to be faster and cleane
> Le 28/01/2012 18:16, Brendan Eich a écrit :
>> I don't think we should change __proto__ unnecessarily from current
>> implementations, including making it an accessor. Neither JSC nor
>> SpiderMonkey does that.
If the spec includes an optional normative definition of __proto__ that
requires it
On Jan 20, 2012, at 4:07 PM, David Bruant wrote:
> * What are all the cases in nowadays browsers where a new
> Object.prototype.__proto__ can be dynamically created? (The only one I
> can think of is same-domain iframe, but I think there exists some weird
> rules for one frame to access another by
On Jan 23, 2012, at 1:11 PM, Brendan Eich wrote:
> Then I think we considered a proposal where private x; bound in a separate
> lexical chain but that chain was searched *only* on right of @. That proposal
> seemed not to have the readability drawback. It also solves the problem you
> show above
On Jan 23, 2012, at 12:27 PM, Brendan Eich wrote:
> No, the private binding form that is desugared from
>
> private foo;
>
> to
>
> const foo = Name.create("foo");
>
> or better (with hygiene to use the right Name, etc.) is lexical in its
> binding structure.
Is the intention here that the
On Jan 22, 2012, at 10:29 PM, Brendan Eich wrote:
>> 1) should .@ member access and @ object literal property definitions permit
>> he property key to be any toString-able value and not just private name
>> values? The current plan of record does not require a private name value in
>> the anal
On Jan 20, 2012, at 4:23 PM, Allen Wirfs-Brock wrote:
> I'm not yet convinced that you need to publicly expose such global object
> properties accessor properties. I think it is possible to hide the
> mechanisms.
I'm strongly inclined to agree with this sentiment – engine implementors might
ch
As well as pragmas, macro-expansion would be a possibility!define fn functionundef fnG.On Jan 20, 2012, at 6:40 PM, Brendan Eich wrote:
Allen Wirfs-Brock
January 20, 2012
5:41 PM
At the TC39 meeting we
were trying to think of pragma candidates.It
wouldn't surprise me if
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
> x = y
> ^{z: w}
On Jan 18, 2012, at 9:05 AM, Oliver Hunt wrote:
> Alas ^ is syntactically ambiguous in the non-argument case:
> foo
> ^{...}
The ambiguity here doesn't seem particularly troubling. Under ASI this parses
in a sensible fashion.
Just a thought, has a prefix ^ been considered?A lambda that takes no arguments could be: ^{ /*...*/ }And a lambda with some arguments: ^(x,y){ /*...*/ }I just find this really readable, the syntax for lambdas that take no arguments is delightfully minimal (just one extra character!), my brain is w
On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote:
> I think the state machine is over-complicating things. What it boils
> down to is that we are defining a new language, ES6-proper (or
> informally ES6 for short). It overlaps with ES5 but does not include
> it (e.g. throws out `with'). Then you
On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote:
> Remember, we are not proposing breaking semantic shifts of meaning for
> existing syntax. So the realistic worry is that you have code with
> arguments[i] aliasing a formal, and this is required for correct operation,
> and you then start using E
On Jan 7, 2012, at 2:22 PM, Claus Reinke wrote:
> Could you please clarify for me: if I get a single-file codebase,
> say jquery's 6k or so lines, will I have to scan the whole file for
> ES6-only features before I can even tell whether to apply ES6
> or ES5 semantics? And will this problem increa
Ah, I see! - Thanks.
On Jan 3, 2012, at 4:58 PM, Brendan Eich wrote:
> On Jan 3, 2012, at 4:50 PM, Gavin Barraclough wrote:
>
>> On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote:
>>
>>> On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote:
>>>
>>&
On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote:
> On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote:
>
>>> ArrayBindingPattern :
>>> [ Elision BindingRestElement ]
>>> [ BindingElementList , Elision BindingRestElement ]
>>
>> It's a grammar bug. Thanks for the proof reading...
>
> Th
On Jan 3, 2012, at 3:27 PM, Brendan Eich wrote:
> You're proposing that we require 'let' be only at the start of statements? If
> so, then destructuring is problematic:
>
> foo();
> let [x] = y;
>
> Did that last line destructure the property named '0' of the object denoted
> by y into a l
On Jan 3, 2012, at 12:18 PM, Brendan Eich wrote:
> Maybe. We tried in 2006-2007 and ran into at least this:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=351515
>
> where 'yield' was used as a parameter name. I dimly recall 'let' in the wild
> but may be misremembering. Perhaps out of parano
On Jan 2, 2012, at 11:45 PM, Axel Rauschmayer wrote:
> Prefix might work, too.
¿x?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Hey Dave,
I'm definitely in favour of removing the opt-in (or at least commonly removing
the need to opt-in), and support the goal of one JS. Since most of the new
syntax only relies on reserved words and, as Brendon stated, yield is only
valid in function* constructs, the only problem so far
As an aside (I'm not arguing for or against inline versioning here) isn't:
use version 6;
more backwards compatible?
For example, consider the following:
"use version 6"; with ({hi:"Hi!"}) alert(hi);
I believe this is a valid program in ES5, that treating "use version 6" as a
d
On Nov 14, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
> Using object exemplars, the named abstraction is itself an instance of the
> abstraction. Some people seem to be perfect happy to only have and use this
> form of object abstraction. However, others prefer to think in a more
> "classical
On Nov 16, 2011, at 5:19 PM, Waldemar Horwat wrote:
> Map/Set:
> Size property should be a getter property with no matching setter. It's
> defined on the property.
> What is its name? size, count, or length? Decide on es-discuss.
Hi Waldemar,
I'm unclear what "It's defined on the property"
Hi Paul,
I tested this a while back, and I hit a couple of web sites using octal escapes
in regexp literals (from memory gmail might have been one, and possibly old
versions of jquery? - but I'm really not sure), I came to the conclusion that
this wasn't going to fly.
However our current octal
On Jul 19, 2011, at 12:17 PM, Allen Wirfs-Brock wrote:
> One issue is that <| conceptually modifies the [[Prototype]] of its RHS. As
> an operator (whether special character or keyword based) we can restrict the
> RHS to be a literal and define the behavior such that no actual mutation of
> [[P
>
>> Might it be reasonable to make private properties be regular properties on
>> the object, with a new 'private' attribute, similar to the existing
>> writable/configurable attributes? From the perspective of code outside of
>> the associated class, an instance's private property would be n
On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote:
>
> On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough
> wrote:
> Hi Mark,
>
> In the harmony classes proposal,
> http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in
> understanding the fol
Hi Mark,
In the harmony classes proposal,
http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in
understanding the following issue:
One or two namespaces for public properties and private instance
variables [RESOLVED two, Mark’s argument]
Do you remember if this ar
On Jul 7, 2011, at 2:59 PM, Mike Samuel wrote:
>> Agreed.
>
> Would that mean that
>
>/^(?:\1x(y)x){2}$/.test("xyxxyx") && !/^(?:\1x(y)x){2}$/.test("xyxyxyx")
>
> If so, V8 agrees with that, the species of monkey in FF 5 does not,
> the JsCore in Safari 533.21 does not, and Rhino does.
Yes
On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote:
> On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel <
>
>> One way to tell whether the group initialized to empty works on an
>> interpreter is to test
>>/^(?:\1x(y)x){2}$/.test("xyxyxyx")
>> which is true in most interpreters, but false in Rh
On Jun 14, 2011, at 3:27 PM, Brendan Eich wrote:
> On Jun 14, 2011, at 2:45 PM, Gavin Barraclough wrote:
>
>> return x * y * z;
>
> This works for the public instance properties, but IIRC some folks object
> that it is too easy to make mistakes vs. formal parame
Hi Mike,
I think there may be a bug in the desugaring. My understanding is that the
only arguments to the quasi tag are the call site id & the SVE, and the SVE
contains only the substitution values, but in the desugaring example literal
portions are being passed to the quasiTag too:
q
Hi,
I was wondering whether there had been any discussion of bringing instance
properties defined in the constructor into the lexical scope of methods , such
that 'this.' and 'private(this).' overhead could be diminished?
For example, given the following class:
class Box {
Box(x, y, z, den
On Jun 13, 2011, at 11:11 PM, Mike Samuel wrote:
>> Also, what is the 'this' object passed to the quasi handler? - might it make
>> sense for 'this' to be the site specific object, rather than the passing
>> this as an argument?
>
> If the quasi handler is a member expression as in foo.bar`baz${b
On Jun 12, 2011, at 4:35 AM, Axel Rauschmayer wrote:
> BTW: “Desugaring” at the beginning of “Semantics” seems mangled.
I was just about to hit send an email saying the same thing!
Also, the section on the default quasi tag the name expandedLP is used, where I
think this should be unescapedLP?
On Jun 7, 2011, at 12:57 PM, Bob Nystrom wrote:
> The main problem that comes to mind is that it doesn't work with anonymous
> classes.
Ah, good point, I hadn't considered anonymous classes. Clearly we could solve
this with a solution specific to these cases (say, "class(){ /*...*/ }" for
ano
Cheers Brendan. I must say, I really like how the class sugar is coming
together. It seems that more closely matching a familiar syntax might make
things a little more approachable for existing OO programmers, but I certainly
see the elegance in using "constructor" directly.
thanks,
G.
On J
Brendan,
Out of interest was a C++/Java style constructor considered, with the
constructor name matching the class name?
cheers,
Gavin.
On May 16, 2011, at 8:02 AM, Brendan Eich wrote:
> On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:
>
>> On 16.05.2011 10:49, Brendan Eich wrote:
>>>
Actually this is fixed in ToT WebKit, have closed the stale bug.
https://bugs.webkit.org/show_bug.cgi?id=56041
cheers,
G.
On Jun 5, 2011, at 5:04 PM, Juriy Zaytsev wrote:
>
>
> On Sun, Jun 5, 2011 at 5:30 PM, Brendan Eich wrote:
> On Jun 3, 2011, at 10:49 AM, Juriy Zaytsev wrote:
>
> > Chr
Hi Mark,
I've fixed this value for Safari in WebKit r79246.
cheers,
G.
On Feb 20, 2011, at 10:04 PM, Mark S. Miller wrote:
> That's what I needed. Thanks.
>
> On Sun, Feb 20, 2011 at 9:53 PM, Rico Wind wrote:
> This was recently fixed in V8, see:
> http://code.google.com/p/chromium/issues/det
On Feb 8, 2011, at 3:35 PM, André Bargull wrote:
> new RegExp("(z)((a+)?(b+)?(c))*").exec("zaacbbbcac")
> => Wrong result in Safari/IE
>
> new RegExp("(.*?)a(?!(a+)b\\2c)
> => Wrong result in Safari/IE
FYI these should be fixed in Safari with a WebKit nightly build.
cheers,
G.
hope this can help move things forwards.
cheers,
G.
On Dec 28, 2010, at 11:53 PM, Geoffrey Sneddon wrote:
> On 29/12/10 02:56, Gavin Barraclough wrote:
>> Hi,
>>
>> In the definition of OctalEscapeSequence, and in the accompanying semantics,
>> it is required at num
Hi,
In the definition of OctalEscapeSequence, and in the accompanying semantics, it
is required at numerous points that the subsequent character is not a
DecimalDigit:
> OctalEscapeSequence ::
> OctalDigit [lookahead ∉ DecimalDigit]
> ZeroToThree OctalDigit [lookahead ∉ DecimalDigit
Hi Lasse,
Thank you for the comprehensive list!
In all these cases we should perhaps first attempt to determine whether these
could just be considered spec compliance issues that ought to be fixed in
implementations. If retaining compatibility with existing code is going to
require continued
According to the ES5 spec a regular expression such as /[\w-_]/ should generate
a syntax error. Unfortunately there appears to be a significant quantity of
existing code that will break if this behavior is implemented (I have been
experimenting with bringing WebKit's RegExp implementation into
70 matches
Mail list logo
