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
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
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]
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 numerous points that the subsequent character
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 ri...@google.com wrote:
This was recently fixed in V8, see:
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 bren...@mozilla.com wrote:
On Jun 3, 2011, at 10:49 AM, Juriy Zaytsev
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:
On
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
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 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${boo}`
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:
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 parameters of the same name.
Understood
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 Rhino1.7 and
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. This is
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
On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote:
On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough barraclo...@apple.com
wrote:
Hi Mark,
In the harmony classes proposal,
http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in
understanding the following issue
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
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 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
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
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
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
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
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 paranoia we
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
On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote:
On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote:
ArrayBindingPattern :
[ Elisionopt BindingRestElementopt ]
[ BindingElementList , Elisionopt BindingRestElementopt ]
It's a grammar bug. Thanks for the proof reading...
The
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:
ArrayBindingPattern :
[ Elisionopt BindingRestElementopt
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 increase
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 ES6
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 your
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
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.
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 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
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 analogous
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 private
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 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
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 to be
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 cleaner to
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 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
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
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 specification
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 be the
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
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
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
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 units).
Last
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 code
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
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
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:53
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 expect the
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,
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:
- would it make sense to name the constructor after the class
(avoiding 'constructor' and 'new')?
I was about to suggest exactly
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
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.
___
es-discuss mailing list
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 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 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
61 matches
Mail list logo
