On 5 Aug 2014, at 02:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
there is already a bug open on this
https://bugs.ecmascript.org/show_bug.cgi?id=2792
Older bug report: https://bugs.ecmascript.org/show_bug.cgi?id=1553
We previously discussed this up at the April TC39 meeting:
On 5 Aug 2014, at 08:40, Mathias Bynens math...@qiwi.be wrote:
On 5 Aug 2014, at 02:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
there is already a bug open on this
https://bugs.ecmascript.org/show_bug.cgi?id=2792
Older bug report: https://bugs.ecmascript.org/show_bug.cgi?id=1553
On 4 Aug 2014, at 18:55, Jason Orendorff jason.orendo...@gmail.com wrote:
We're talking about something different here, legacy *decimal* integer
literals starting with 0 and containing 8 or 9. As far as I know, no
version of ES has ever permitted this kind of nonsense, but supporting
it is
On Aug 4, 2014, at 9:55 AM, Jason Orendorff wrote:
On Mon, Aug 4, 2014 at 11:43 AM, Mark S. Miller erig...@google.com wrote:
Isn't the early error required only for strict code?
There is actually no such Early Error in the ES6 spec, right? We're talking
about what the BNF allows.
On 5 Aug 2014, at 16:20, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We're only talking about Annex B, non-strict. Right?
All engines are going to implement this anyway, so why make it Annex B only? I
wouldn’t restrict it to non-strict mode either, as this decision seems to be
purely
Because of compatibility constraints, JS history can generally proceed only
in an additive manner, which means a steady degradation of quality along
the simplicity dimension. An opt-in mode switch is the only way to escape
that dynamic. Strict mode is the only one we've got, and the only one we're
On 5 Aug 2014, at 16:56, Alex Kocharin a...@kocharin.ru wrote:
What about allowing one-digit numbers with leading zeroes? 07 equals to 7
no matter whether it parsed as an octal or as a decimal. Thus, no harm there.
That wouldn’t solve the problem. Consider e.g. `01234567` (i.e. `342391`) vs.
On 5 Aug 2014, at 17:05, Mark S. Miller erig...@google.com wrote:
Because of compatibility constraints, JS history can generally proceed only
in an additive manner, which means a steady degradation of quality along the
simplicity dimension. An opt-in mode switch is the only way to escape
On 5 Aug 2014, at 17:05, Mark S. Miller erig...@google.com wrote:
Strict mode should not accept octal literals.
The literals under discussion (e.g. `08` and `09`) are not octal literals.
___
es-discuss mailing list
es-discuss@mozilla.org
On Tue, Aug 5, 2014 at 8:14 AM, Mathias Bynens math...@qiwi.be wrote:
On 5 Aug 2014, at 17:05, Mark S. Miller erig...@google.com wrote:
Because of compatibility constraints, JS history can generally proceed
only in an additive manner, which means a steady degradation of quality
along the
05.08.2014, 19:07, Mathias Bynens math...@qiwi.be:
On 5 Aug 2014, at 16:56, Alex Kocharin a...@kocharin.ru wrote:
What about allowing one-digit numbers with leading zeroes? 07 equals to 7
no matter whether it parsed as an octal or as a decimal. Thus, no harm there.
That wouldn’t solve the
On 5 Aug 2014, at 17:19, Mark S. Miller erig...@google.com wrote:
On Tue, Aug 5, 2014 at 8:17 AM, Mathias Bynens math...@qiwi.be wrote:
The literals under discussion (e.g. `08` and `09`) are not octal literals.
Strict mode should reject these even more vehemently! (Allen, can we have an
According to the spec, the toISOString is currently defined to return a string
in the format -MM-DDTHH:mm:ss.sssZ.
Specifically, there's a 3-digit fractional part introduced by a . (that's the
.sss above) appended to the seconds.
It is my understanding of the ISO8601 spec that fractional
f you read the Loader source carefully you can see that Jason fixed the
Loader to support inheritance. But his fix does not allow classes to
inherit the platform's loading behavior. That behavior is given in options
properties passed to instances. By defining the system loader as an
instance of a
# July 29 2014 Meeting Notes
Brian Terlson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Sebastian Markbage (SM), Istvan Sebestyen
# July 30 2014 Meeting Notes
Brian Terlson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Sebastian Markbage (SM), Istvan Sebestyen
# July 31 2014 Meeting Notes
Brian Terlson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Sebastian Markbage (SM), Istvan Sebestyen
No Math.TAU in Harmony, per the meeting notes:
http://esdiscuss.org/notes/2014-07-31#5-1-math-tau
MarkM's argument fits on one line: one letter shorter, not well known,
not well taught. PI is known, taught and ubiquitous.
This is a courtesy FYI and (I hope) a tombstone for this thread. Don't
On Aug 5, 2014, at 8:38 AM, Mathias Bynens wrote:
On 5 Aug 2014, at 17:19, Mark S. Miller erig...@google.com wrote:
On Tue, Aug 5, 2014 at 8:17 AM, Mathias Bynens math...@qiwi.be wrote:
The literals under discussion (e.g. `08` and `09`) are not octal literals.
Strict mode should reject
JavaScriptCore has never allowed octal sequences (anything other than a . or x
after 0) in strict mode, and we haven't had any problems with it.
--Oliver
On Aug 5, 2014, at 11:13 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 5, 2014, at 8:38 AM, Mathias Bynens wrote:
On 5
Mark S. Miller wrote:
Because of compatibility constraints, JS history can generally proceed
only in an additive manner, which means a steady degradation of
quality along the simplicity dimension. An opt-in mode switch is the
only way to escape that dynamic.
Not really relevant here, though:
On Aug 5, 2014, at 9:07 AM, Mameri, Fred (HBO) wrote:
According to the spec, the toISOString is currently defined to return a
string in the format -MM-DDTHH:mm:ss.sssZ.
Specifically, there’s a 3-digit fractional part introduced by a . (that’s the
“.sss above) appended to the seconds.
Some differences/oddities I noticed between referencing and invoking
`super`. I briefly discussed this with Erik Arvidsson at
https://github.com/google/traceur-compiler/issues/1220. In essence, if you
can invoke in two seperate ways, it seems logical that you should be able
to reference in those
On Aug 5, 2014, at 6:06 PM, Brett Andrews wrote:
Some differences/oddities I noticed between referencing and invoking `super`.
I briefly discussed this with Erik Arvidsson at
https://github.com/google/traceur-compiler/issues/1220. In essence, if you
can invoke in two seperate ways, it
Thanks for your response, Allen. I'm not sure what convincing I can do. To
me it seems odd that `super()` is the same as `super.submit()` but `super`
is not the same as `super.submit`, but perhaps to others that seems
perfectly fine. An alternative to this suggestion would be `super()` should
not
I sympathize; I have always found the fact that bare `super()` works to be
confusing.
From: Brett Andrewsmailto:brett.j.andr...@gmail.com
Sent: 2014-08-05 23:09
To: Allen Wirfs-Brockmailto:al...@wirfs-brock.com
Cc:
On Tuesday, August 5, 2014, Domenic Denicola dome...@domenicdenicola.com
wrote:
I sympathize; I have always found the fact that bare `super()` works to
be confusing.
When a bare super() call appears in a method (whether constructor or not)
it can only have _one_ _meaning_ and that's a call
On Wed, Aug 6, 2014 at 12:38 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tuesday, August 5, 2014, Domenic Denicola dome...@domenicdenicola.com
wrote:
I sympathize; I have always found the fact that bare `super()` works to
be confusing.
When a bare super() call appears in a method
My preference would be for `super()` to remain as-is, and give `super` the
equivalent semantics: reference a method of the same name in the parent
class (as opposed to invoke). I only provided the alternative since my
ultimate view is that `super` and `super()` should function similarly
(either
use of unqualified super in this manner has a long history in OO programming
language. It’s too late this evening for me to dig up references for you but
it dates to at least language designs of the early 1980. Smalltalk didn’t do
it, but mainly because it does doesn’t use a function
On Aug 5, 2014, at 10:11 PM, Brett Andrews brett.j.andr...@gmail.com wrote:
My preference would be for `super()` to remain as-is, and give `super` the
equivalent semantics: reference a method of the same name in the parent class
(as opposed to invoke). I only provided the alternative since
31 matches
Mail list logo
