Hi Allen,
Thanks for taking the time to read and respond. I've read your reply in
detail and I feel like it deserves a point-by-point response, but I think
the following might get us on the same page more quickly.
The important point to consider is that I'm *not* comparing this:
A.)
let
Axel Rauschmayer wrote:
private x,y; is syntactically tricky inside an object initializer. The previous
consensus was to use
private { x, y }
I don't like object literal syntax, it takes over like a weed. If
classes are worth adding with higher-level (but still desugarable)
semantics
That makes sense.
One thing to look out for: Not loosing one’s mind due to subtle syntactic
differences between modules, class declarations and object initializers (and
possibly cascades). There needs to be consistency. But (implicit) rules such as
“colon = separator is comma” and “equals =
Kevin Smith wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
The point I'm trying to drive home is that the above is no better
(worse, in fact) from a user experience standpoint, than what I have
now.
Brendan Eich wrote:
We'll get this strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:steve_levithan_regexp_api_improvements
onto the agenda for the next TC39 meeting.
Neat-o. I mentioned in the blog post referenced there [1] that I'd be doing
a separate write-up with my opinionated
Given the recent go at finding alternative syntax for the | operator, I
thought about it and decided to split the functionality between creating
instances using alternative prototypes, and the other side of the fence
making reusable extended objects easier to make.
Its a little long so I threw it
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
let Blah = BaseClass | function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
1. I don't like the imperative approximations of a declarative API.
Since we're
The recent feedback is relating to Math functions is great, but it's hard to
track it all as es-discuss postings. To address this, I've have created a
tracking bug at https://bugs.ecmascript.org/show_bug.cgi?id=309 to keep
track of this feedback.
Thanks. I've added some comments from
The example you gave produces a constructor that wraps a handful of
instance method definitions along with several function declarations -
which I'm arguing could just as easily be outside of that function
declaration, but inside of an IIFE.
There are two issues here:
1) “Private methods”
Why should e.g. '\u2xao' throw an error? I can’t find this in the spec, but
Test262 actually has a test for this behavior so I must be missing
something obvious.
I know `UnicodeEscapeSequence` is defined as follows:
UnicodeEscapeSequence :: u HexDigit HexDigit HexDigit HexDigit
But since
Claus Reinke wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
let Blah = BaseClass | function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
1. I don't like the imperative approximations of a declarative API.
Since we're designing new
On Sat, Mar 17, 2012 at 11:16 AM, Mathias Bynens math...@qiwi.be wrote:
Why should e.g. '\u2xao' throw an error? I can’t find this in the spec, but
Test262 actually has a test for this behavior so I must be missing something
obvious.
I know `UnicodeEscapeSequence` is defined as follows:
On Sat, Mar 17, 2012 at 9:00 AM, Steven L. steves_l...@hotmail.com wrote:
I thought so, too. See [2] from Waldemar (May 24-26 rough meeting notes).
Specifically, he stated Lookbehind support is promoted to required
normative.
Are there any plans for which kind of look-behind to allow? Literal
I would simply apply same logic we have already for the look ahead ... or
you think that would cause problems?
On Sat, Mar 17, 2012 at 1:07 PM, Lasse Reichstein
reichsteinatw...@gmail.com wrote:
On Sat, Mar 17, 2012 at 9:00 AM, Steven L. steves_l...@hotmail.com
wrote:
I thought so, too. See
Eric Corry wrote:
However I think we probably do want the /u modifier on regexps to
control the new backward-incompatible behaviour. There may be some
way to relax this for regexp literals in opted in Harmony code, but
for new RegExp(...) and for other string literals I think there are
rather
Andrea Giammarchi wrote:
I would simply apply same logic we have already for the
look ahead ... or you think that would cause problems?
As has been discussed previously, it is nontrivial to implement infinite-length
lookbehind efficiently (where you’re not just testing /(?:lookbehind)$/ against
I see there was a bunch of work done to possibly introduce 128-bit
IEEE754r DFP back in the ES4 days:
http://wiki.ecmascript.org/doku.php?id=proposals:decimals=decimal
Has any work been done since ES4 to introduce a DFP type?
-Andrew
___
es-discuss
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special case for function rhs, ie, to interpret
(p | obj) simply
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using : instead of |, shorten Email.prototype to just Email
let email = Email:russell.legg...@gmail.com;
Basically you are saying that : becomes an expression operator. However, that
creates an ambiguity (and potential
How about a couple of new formats for Number ...
Number.prototype.toEngineering
This is similar to the normalised 'toExponential', but the exponent is a
multiple of 3 and there are 1, 2, or 3 digits before the decimal point. The
format makes it visually easy to relate a string representation
Isn't it used in E4X (not that I used it or care for it; but I recall I
have read somewhere :: is not usable for this reason... I would
otherwise proposed it already ;-) )?
Herby
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using : instead of |,
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using : instead of |, shorten Email.prototype to just Email
let email = Email:russell.legg...@gmail.com;
Basically you are saying that :
Allen Wirfs-Brock wrote:
I not recall why we haven't seriously considered :: as an alternative
to |. It certainly eliminates all the typography issues.
Because we had agreed to reserve :: for guards:
http://wiki.ecmascript.org/doku.php?id=strawman:guards
/be
Currently, | sets the [[prototype]] field of the RHS object,
and -if the RHS is a function literal- also specifies the [[prototype]]
field of objects generated from it. I suggest to remove that special
case for function RHS.
Ultimately, this is my suggestion as well. And for class
On Mar 17, 2012, at 9:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I not recall why we haven't seriously considered :: as an alternative to |.
It certainly eliminates all the typography issues.
Because we had agreed to reserve :: for guards:
On Mar 17, 2012, at 9:14 AM, Russell Leggett wrote:
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using : instead of |, shorten Email.prototype to just Email
let email =
On Mar 17, 2012, at 12:18 PM, Kevin Smith khs4...@gmail.com wrote:
Currently, | sets the [[prototype]] field of the RHS object,
and -if the RHS is a function literal- also specifies the [[prototype]]
field of objects generated from it. I suggest to remove that special
case for function RHS.
Following on from Number.prototype.toHexExponential, it would be nice if
parseFloat could then convert this format back to Number.
And parseFloat should ignore a 0x or 0X between the leading sign (if
any) and the main string.
E.g. -0x123.B4p+12
On Mar 17, 2012, at 12:31 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 17, 2012, at 9:14 AM, Russell Leggett wrote:
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using :
Wouldn't it be better to use 'as' for guards? Seems more intuitive and
easier to type
let A as Number = 3;
let B as Email = x...@google.com;
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
However, it is'nt a reserved keyword. But I don't
On Mar 17, 2012, at 9:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I not recall why we haven't seriously considered :: as an alternative to |.
It certainly eliminates all the typography issues.
Because we had agreed to reserve :: for guards:
or we could use ::: see
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
Given the recent go at finding alternative syntax for the | operator, I
thought about it and decided to split the functionality between creating
instances using alternative prototypes, and the other side of the fence
making reusable
2012/3/17 Steven L. steves_l...@hotmail.com:
Eric Corry wrote:
However I think we probably do want the /u modifier on regexps to
control the new backward-incompatible behaviour. There may be some
way to relax this for regexp literals in opted in Harmony code, but
for new RegExp(...) and for
2012/3/17 Andrew Paprocki and...@ishiboo.com:
I see there was a bunch of work done to possibly introduce 128-bit
IEEE754r DFP back in the ES4 days:
http://wiki.ecmascript.org/doku.php?id=proposals:decimals=decimal
Has any work been done since ES4 to introduce a DFP type?
Hopefully, no, but
On Sat, Mar 17, 2012 at 1:09 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
Given the recent go at finding alternative syntax for the | operator, I
thought about it and decided to split the functionality between creating
instances using
Le 17/03/2012 00:50, Jonas Höglund a écrit :
On Sat, 17 Mar 2012 00:18:48 +0100, David Bruant bruan...@gmail.com
wrote:
A Person knows one secret and has methods like .eat(), .walk()... There
is no method in the Person interface to reveal the secret either
directly or indirectly.
A
On Mar 16, 2012, at 11:42 PM, Kevin Smith wrote:
Hi Allen,
Thanks for taking the time to read and respond. I've read your reply in
detail and I feel like it deserves a point-by-point response, but I think the
following might get us on the same page more quickly.
The important point
Eric Corry wrote:
Disagree with adding /u for this purpose and disagree with breaking
backward
compatibility to let `/./.exec(s)[0].length == 2`.
Care to enlighten us with any thinking behind this disagreeing?
Sorry for the rushed and overly ebullient message. I disagreed with /u for
Yes, Sam Ruby prototyped a new Decimal built-in for SpiderMonkey, with
operators. This was in mid-2008 when ES4 was going down. See
https://bugzilla.mozilla.org/show_bug.cgi?id=445178
TC39 rejected hardcoding IEEE DFP into JS at the 2008 fall Kona meeting:
Le 17/03/2012 00:36, John J Barton a écrit :
On Fri, Mar 16, 2012 at 4:18 PM, David Bruant bruan...@gmail.com wrote:
...
This is a piece of cake with Java's protected. It is much convoluted in
JavaScript. I think this kind of problem being hard to solve in
JavaScript is the reason why so many
Supported yet by the Dart-to-JS compiler? How is the performance?
http://wiki.ecmascript.org/doku.php?id=strawman:bignums
could help -- of course we did not hear about Dart's requirements in
time for ES6.
Arguably Dart doesn't matter. Lots of languages with bignums compile to
JS. We could
Steven, sorry, I wasn't aware of your proposal for /u when I inserted the note
on this flag into my proposal. My proposal was inspired by the use of /u in
PHP, where it switches from byte mode to UTF-8 mode. We'll have to see whether
it makes sense to combine the two under one flag or use two -
2012/3/17 Norbert Lindenberg ecmascr...@norbertlindenberg.com:
Steven, sorry, I wasn't aware of your proposal for /u when I inserted the
note on this flag into my proposal. My proposal was inspired by the use of /u
in PHP, where it switches from byte mode to UTF-8 mode. We'll have to see
On Mar 17, 2012, at 8:39 AM, Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special
2012/3/17 Steven L. steves_l...@hotmail.com:
I further objected because I think the /u flag would be better used as a
ASCII/Unicode mode switcher for \d\w\b. My proposal for this is based on
Python's re.UNICODE or (?u) flag, which does the same thing except that it
also covers \s (which is
On Mar 17, 2012, at 10:20 , Erik Corry wrote:
2012/3/17 Steven L. steves_l...@hotmail.com:
Eric Corry wrote:
However I think we probably do want the /u modifier on regexps to
control the new backward-incompatible behaviour. There may be some
way to relax this for regexp literals in opted
On Mar 17, 2012, at 11:58 , Erik Corry wrote:
2012/3/17 Steven L. steves_l...@hotmail.com:
I further objected because I think the /u flag would be better used as a
ASCII/Unicode mode switcher for \d\w\b. My proposal for this is based on
Python's re.UNICODE or (?u) flag, which does the same
Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special case for function rhs, ie, to
On Sat, Mar 17, 2012 at 11:37 AM, David Bruant bruan...@gmail.com wrote:
Le 17/03/2012 00:36, John J Barton a écrit :
On Fri, Mar 16, 2012 at 4:18 PM, David Bruant bruan...@gmail.com wrote:
...
This is a piece of cake with Java's protected. It is much convoluted in
JavaScript. I think this
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 8:39 AM, Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and
Number.prototype.toHexExponential
This is similar to 'toExponential' but is in the normalised hexadecimal
form instead of decimal.
E.g. 1.4A2p+4
The letter 'p' corresponds to decimal's 'e', and means times 2 to the
power of.
The *binary* exponent is represented in signed *decimal*.
The hex
François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intuitive and
easier to type
let A as Number = 3;
let B as Email = x...@google.com;
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
However, it is'nt a reserved keyword. But I don't think
On Mar 17, 2012, at 1:20 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
...
(function () {}) creates two object, not one. We have to set the
[[Prototype]] of both objects to something. In deciding how to do
this it is important to look at the role of each member of that
object
On 03/17/2012 01:55 PM, François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intuitive and
easier to type
let A as Number = 3;
let B as Email = x...@google.com;
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
On Sat, Mar 17, 2012 at 2:28 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I would simply apply same logic we have already for the look ahead ... or
you think that would cause problems?
I'm not sure it even makes sense.
ES RegExps are backtracking based, and it makes a difference in
Eric Corry wrote:
I further objected because I think the /u flag would be better used as a
ASCII/Unicode mode switcher for \d\w\b. My proposal for this is based on
Python's re.UNICODE or (?u) flag, which does the same thing except that
it
also covers \s (which is already Unicode-based in ES).
2012/3/18 Steven L. steves_l...@hotmail.com:
Eric Corry wrote:
I further objected because I think the /u flag would be better used as a
ASCII/Unicode mode switcher for \d\w\b. My proposal for this is based on
Python's re.UNICODE or (?u) flag, which does the same thing except that
it
also
Lasse Reichstein wrote:
I would simply apply same logic we have already for the look ahead ... or
you think that would cause problems?
I'm not sure it even makes sense.
ES RegExps are backtracking based, and it makes a difference in which
order alternatives are tried. Greedy matching is
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5
Has some new material relevant to issue we discuss on this list. Enjoy!
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
I'm seeing this for the first time now. Sorry for reviving old news.
On 2011-06-03, Brendan Eich wrote:
Kyle Simpson wrote:
I propose a /n flag for regular expressions, which would swap the
default capturing/non-capturing behavior between ( ) and (?: )
operators (that is, ( ) would not
While you wouldn't use A because it can't express the full semantics of C,
that doesn't mean that many users who currently have to write B wouldn't
prefer to be able to write A.
Yes - many (most?) users will benefit from being able to write A. But the
thrust of my argument is not that there
61 matches
Mail list logo
