So i've been looking at the JSON object grammar and have been talking
to brendan and i'm getting somewhat conflicting information.
The grammars on json.org and in the ES5 spec both prohibit leading 0's
on any number, but the various implementations disagree with this.
json2.js (from
On Jun 2, 2009, at 7:26 PM, Mark S. Miller wrote:
Since octal wasn't an official part of ES3, remains absent from
official ES5, and is now explicitly prohibited from ES5/strict, it
is good that it is not specified by JSON. I am surprised that
json2.js accepts the syntax, and even more
On Jun 2, 2009, at 11:09 PM, Rob Sayre wrote:
On 6/3/09 1:56 AM, Allen Wirfs-Brock wrote:
My inclination would be to require ES5 implementation to exactly
conform the whatever JSON grammar we provide and to throw syntax
errors if the input doesn't exactly conform to the grammar. (in
On Jun 3, 2009, at 11:18 AM, Rob Sayre wrote:
On 6/3/09 2:12 PM, Oliver Hunt wrote:
1.) leading zeros are parsed as decimal numbers (octal seems like
a bug no matter what, per MarkM)
IE8 and V8's JSON implementation, and json2.js at json.org all
interpret 010, as octal (eg. 8), and 009
On Jun 3, 2009, at 2:15 PM, Mark S. Miller wrote:
On Wed, Jun 3, 2009 at 2:10 PM, Robert Sayre say...@gmail.com wrote:
OK, so, all such deviations will be considered bugs by
implementations
that purport to conform. Right?
Yes.
Awesome.
--Oliver
The spec for JSON doesn't describe the exact behaviour of the replacer
argument to stringify when the replacer is an array. The relevant
text (from 15.12.3) is
If Type(replacer) is object and the [[Class]] internal property of
replacer is Array, then
Let K be an internal List
On Jun 5, 2009, at 12:01 PM, Allen Wirfs-Brock wrote:
I must be dense this morning but I don’t see how the two calls to
[[Get]] occurs in the algorithm. The first call to [[Get]] for a
property key in object holder occurs in step 1 of Str. How does the
second call occur? The only place I
On Aug 25, 2009, at 9:32 AM, Hallvord R. M. Steen wrote:
On Sat, 04 Jul 2009 13:49:01 +0200, Hallvord R. M. Steen
hallv...@opera.com wrote:
Another question: The JSON grammar says
JSONNumber ::
-opt DecimalIntegerLiteral JSONFraction opt ExponentPart opt
JSONFraction ::
. DecimalDigits
2) The grammar and an existing test in the json.org test suite
disallows final commas in array input (JSON.parse('[1,]') should
apparently throw) - IE8, Safari 4 and Firefox 3.5 all seem to
happily accept it though, as does the yet-to-go-public Opera
implementation. I'd like some
Quick word about the test suite: it's current home is http://testsuites.opera.com/JSON/
where you can have a look at the README, load runner.htm to run all
tests (Warning: if you do that in IE8 something makes it eat all
your memory and make the PC entirely unusable!) or browse through
Octal values are completely specified -- the lexer defined in ES5
and json.org disallows a leading 0 on any value not between -1 and
1.
Right - I think the test itself is valid, so I just need to fix the
comment saying it's an unspecified assertation, right?
(test is
On Aug 26, 2009, at 4:50 PM, Hallvord R. M. Steen wrote:
On Thu, 27 Aug 2009 01:22:46 +0200, Oliver Hunt oli...@apple.com
wrote:
Octal values are completely specified -- the lexer defined in ES5
and json.org disallows a leading 0 on any value not between -1 and
1.
Good to hear
On Aug 26, 2009, at 4:22 PM, Oliver Hunt wrote:
Yup. You may also want tests for use of replacer arrays and
functions, etc
On this topic, i'm fixing an issue in our handling of reviver
functions in JSON.parse and noticed that json2.js and the JSON.parse
specification differ
] On Behalf Of Hallvord R. M. Steen
Sent: Thursday, August 27, 2009 4:44 AM
To: Oliver Hunt
Cc: es-discuss@mozilla.org
Subject: a test for stringify whitelist which WebKit fails
Hi Oliver,
I'm curious about this TC - it appears to be WebKit against the
rest of
us, but it will take me some
Hi Hallvord,
I was looking at webkit's failure of test 004 and 005 -- clamping of
gap to 10 characters -- and it actually looks like you've missed out
step 8.b.iii if gap is not the empty string -- your regexp for
testing the result should have a space character following the colon.
On Sep 17, 2009, at 11:52 PM, Garrett Smith wrote:
ES5 Committee,
In Function.prototype.toString, the representation should be a
Function Definition. The current text requires a
FunctionDeclaration. Many (if not most) implementations today, do
not follow the standard in the following cases:
How?
javascript: alert(function(){})
Safari 4 elerts:
function () {}
The current specification doesn't allow that.
Why not?
The current specification requires the result of
Function.prototype.toString to be a FunctionDeclaration and
function(){} is not a FunctionDeclaration representation.
On Sep 24, 2009, at 3:55 PM, Charles Jolley wrote:
Given your example, a named function expression would do the job
trivially:
ClassB = ClassA.extend({
foo: function foo() {
foo.base.apply(this, arguments); // calls super!
// other code
}
});
This works but, as I said, this
On Sep 26, 2009, at 3:36 PM, Cameron McCormack wrote:
Allen Wirfs-Brock:
Every place the WebIDL ECMAScript binding overrides an ECMAScript
specification
internal method is a concern as these are special case extensions
to the ECMAScript
semantics. As language designers we need to
Currently FF3.5.4 doesn't properly apply replacer functions, but
Safari 4, WebKit, IE8, and Chrome 3 work fine for this task.
For the purpose of discussion webkit and safari (and epiphany, and
arora, ...) are synonymous -- chrome represents the only version of
webkit using a unique JS
On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:
Oliver Hunt wrote:
On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
Charles Jolley wrote:
This looks like a good approach. I wonder if the Data/DataBuilder
distinction could be handled better by using the Object.freeze
On Dec 7, 2009, at 3:52 AM, Kevin Curtis wrote:
No spec as yet - more a speculative prototype.
The patch creates a subdir 'ast-test' in the V8 dir which contain a
range of JS source examples covering the ECMAScript grammar. These
examples (and any other JS scripts) can be parsed to JsonML
On Dec 7, 2009, at 3:21 PM, ihab.a...@gmail.com wrote:
On Mon, Dec 7, 2009 at 3:10 PM, David-Sarah Hopwood
david-sa...@jacaranda.org wrote:
... programmers of AST-processing applications will see this
serialization when debugging, and it is likely to appear in test
cases for such
snip
OTOH, if we standardize an AST format, then presumably we'll be adding
a source-AST API function that uses the implementation's existing parser.
I'd be worried about assuming that this is an obvious/trivial thing for
implementations to do, you're effectively requiring that the internal
On Dec 8, 2009, at 2:18 AM, David-Sarah Hopwood wrote:
Oliver Hunt wrote:
snip
OTOH, if we standardize an AST format, then presumably we'll be adding
a source-AST API function that uses the implementation's existing parser.
I'd be worried about assuming that this is an obvious/trivial
On Jan 18, 2010, at 12:14 PM, Brendan Eich wrote:
On Jan 18, 2010, at 11:58 AM, Mark S. Miller wrote:
On Mon, Jan 18, 2010 at 10:25 AM, Brendan Eich bren...@mozilla.com wrote:
On Jan 18, 2010, at 10:20 AM, Mark S. Miller wrote:
I simply don't understand what you mean by the phrase
On Jan 18, 2010, at 5:41 PM, Brendan Eich wrote:
On Jan 18, 2010, at 5:20 PM, ihab.a...@gmail.com wrote:
On Mon, Jan 18, 2010 at 4:54 PM, Brendan Eich bren...@mozilla.com wrote:
That's right -- no races, execution still seems single-threaded. Wherefore
the special form, although if this
On May 1, 2010, at 1:27 PM, Brendan Eich wrote:
A simple solution that would allow maintaining the
above mentioned 'invariant' in most cases and allow breaking it when
necessary would involve a flag passed into the 'get' handler
indicating that the property is about to be 'called'. What
On May 7, 2010, at 12:56 PM, stay wrote:
Really? How could sites possibly depend on being able to mark
properties non-enumerable but still have them appear in a for-in loop?
Sorry, shadowing with a non-enumerable property is new to ES5, I was meaning
the behaviour i described is what we need
* never attaches a non-strict method to a wrapper or Object prototype
that returns this
The existence for a non-strict method anywhere within the whole program
violates my first condition.
On this note are builtin functions considered to be strict or non-strict? Take
the following stupid
On May 13, 2010, at 10:21 PM, Alex Russell wrote:
On May 13, 2010, at 5:15 PM, Vladimir Vukicevic wrote:
This is difficult to do, given the goals of typed arrays -- they wouldn't
behave like normal Arrays in most meaningful ways.
Sounds like a bug to be fixed ;-)
At the core, an
On May 18, 2010, at 9:04 AM, Mark S. Miller wrote:
On Tue, May 18, 2010 at 12:22 AM, Erik Corry erik.co...@gmail.com wrote:
2010/5/18 Kenneth Russell k...@google.com:
On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Vladimir Vukicevic
On May 20, 2010, at 11:37 AM, Irakli Gozalishvili wrote:
Hi,
Sorry if my question is stupid or does not really belongs here. I will be
thankful to get some clarification on es specs since I just discovered that
my interpretation of how getter / setters are supposed to behave appears to
So for a non host object o,
o.x = o.x - 1
should yield a number regardless of the details of any setter for x on
o, assuming o is not frozen and said setter returns normally.
The assignment operator is defined in the language fairly clearly in a way that
means that the behaviour is
On Jun 2, 2010, at 11:14 AM, Brendan Eich wrote:
On Jun 1, 2010, at 6:15 PM, Waldemar Horwat wrote:
b = a[i];
a[i].x += 1;
Now b.x also reflects the new value of a[i].x; i.e. b is an alias, not a
mutable copy. The same thing would happen if one had mutated b.x.
That leads to a
On Jun 2, 2010, at 4:43 PM, Oliver Hunt wrote:
I cannot think of a case where b should not be an alias to a[i] if b is not
an alias to a[i] then the code
Should be:
I cannot think of a case where b should not be an alias to a[i]. If b is not
an alias to a[i] then the code:
...
Hooray
On Jun 8, 2010, at 8:46 PM, Garrett Smith wrote:
Today I looked for a good json regexp tester and finding nothing,
decided to write one.
The strategy that occurred to me was to first define a regex for the
literal components (ES5 lumps literal value into the JSONValue
alongside JSONObject
On Jun 22, 2010, at 6:06 PM, Douglas Crockford wrote:
On 6/22/2010 5:28 PM, Garrett Smith wrote:
Most of the questions on Grammar were answered in this thread,
however, the question of U+0009 as a JSONStringCharacter remains. All
major browsers allowi U+0009 in JSONString. What should the
On Jun 22, 2010, at 7:07 PM, Dean Landolt wrote:
On Tue, Jun 22, 2010 at 9:34 PM, Oliver Hunt oli...@apple.com wrote:
But that's the rub -- the JSON spec cannot be changed. It (intentionally) has
no version number. ECMA could superset it -- ES-JSON, if you will -- which
could
On Jun 22, 2010, at 8:17 PM, Dean Landolt wrote:
There are countless JSON parsers in the wild -- likely 1 for almost every
obscure language in existence, not counting all the one-offs. Any number of
these were written with the expectation of not expecting control characters
-- not too
Microsoft has just recently (as far as i was aware) added JS tests to the IE
testing center and a number of the tests test the value of someFunction.length,
I can't see where these values are actually specified for functions with
optional arguments, what am I missing?
--Oliver
On Jul 23, 2010, at 10:32 AM, Brendan Eich wrote:
On Jul 23, 2010, at 10:27 AM, Oliver Hunt wrote:
[Good point about LL(∞) snipped.]
* To give you an idea of how important parsing is, the 280 North folk once
told me that parsing made up 25% of the load time for 280 Slides.
Ollie
On Jul 29, 2010, at 2:47 PM, Waldemar Horwat wrote:
Comprehensions: To be useful, need to have a bunch of basic helpers
such as range(), properties(), values(), etc. with short names that
can be used to construct comprehensions. These will be added to the
proposal.
Would like to be able
On Jul 30, 2010, at 2:56 PM, Brendan Eich wrote:
On Jul 30, 2010, at 2:47 PM, felix wrote:
On 7/30/10 14:37, Brendan Eich wrote:
For Harmony, we do not propose to standardize |for each|. Instead, the
iteration and array comprehensions proposals for Harmony (see the wiki)
propose that
On Jul 30, 2010, at 3:35 PM, Brendan Eich wrote:
On Jul 30, 2010, at 3:02 PM, Oliver Hunt wrote:
On Jul 30, 2010, at 2:56 PM, Brendan Eich wrote:
To avoid this confusion you can add new syntax (|for each| or whatever,
doesn't matter). I've argued in recent posts that it is better from
It does seem reasonable to disallow new lines in that context.
--Oliver
On Aug 24, 2010, at 1:53 PM, Allen Wirfs-Brock wrote:
Consider the following JavaScript code fragment:
var x=foo.
if (ab) -bar;
If this showed up in real code, it would probably be either as a typo where
either
What is the expected behaviour of ToPropertyDescriptor if I provide undefined
values for the get or set properties? eg.
var o={};
Object.defineProperty(o, foo, {get: undefined});
Object.getOwnPropertyDescriptor(o, foo); // ???
--Oliver
___
es-discuss
The other problem with JSLint is that it can't run all of the code so JSLint
won't pick up the runtime error in
function f() {
use strict;
return this.foo;
}
f();
I've seen a couple of sites that would break due to this.
--Oliver
On Sep 8, 2010, at 3:16 PM, Marek Stępień wrote:
On
On Sep 13, 2010, at 2:02 PM, Mark S. Miller wrote:
On Mon, Sep 13, 2010 at 1:18 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
I didn't finished a detailed reading yet, but from the brief scanning,
syntactically, I think = and trait class are not needed.
* I used trait
Section 10.6 describes the creation of the arguments object, most of which
makes sense but i think there's a typo in step 14.
Step 13 describes the definition of the callee property of the arguments object
if strict == false
Step 14 describes the creation of the _caller_ property if strict ==
and caller are poisoned. arguments.caller is
poisoned in step 14.b as you noticed. On the next page, arguments.callee is
poisoned in step 14.c
On Sun, Sep 26, 2010 at 3:00 AM, Oliver Hunt oli...@apple.com wrote:
Section 10.6 describes the creation of the arguments object, most of which
makes
I really don't like the idea of using proxies simply to essentially create an
array with a custom prototype.
My understanding of what is wanted (in terms of subtyping an array) is an
ability to have something like
var arr = new MyArray()
Where 'new MyArray' behaves in essentially the same
On Nov 11, 2010, at 11:30 AM, Dmitry A. Soshnikov wrote:
OTOH, negative indices, are even not array indices. I.e.
var a = [1,2];
a[-1] = 0;
print(a); // 1,2
print(a.length); // 2
From this viewpoint -- for what are they? Seems again, `-n` notations for
arrays and strings is useful as
So, do I understand correctly that you are against this feature and don't
like it? (Just another question -- are you aware that it used in Python,
Ruby, Perl, Coffee, other langs?)
The fact that other languages have a feature is not relevant, the problem is
the drastic change to semantics
On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote:
My arguments in favor of keeping the existing for-in syntax and making it
meta-programmable:
- Simplicity. Don't underestimate the complexity creep of introducing a new
looping construct. Many small changes add up quickly. Especially for
On Nov 22, 2010, at 11:49 AM, Brendan Eich wrote:
On Nov 22, 2010, at 11:14 AM, Oliver Hunt wrote:
On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote:
My arguments in favor of keeping the existing for-in syntax and making it
meta-programmable:
- Simplicity. Don't underestimate
The most frequent (in my hearing) unsatisfied expectation of users of for-in
is not that it is a second form after the C-based for(;;) -- there's no
mention of for(;;). Rather, it is that for (v in [1,2,3]) fails to iterate
1,2,3, instead enumerating 0,1,2.
We can't satisfy this
Just giving my feedback to this (so it's recorded somewhere other than my head).
I find the apparent necessity of conflating syntax and semantics irksome, i'd
much rather that there be two distinct discussions one of syntax and the other
for semantics of soft-fields, private names, gremlins,
On Dec 21, 2010, at 4:25 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
Just giving my feedback to this (so it's recorded somewhere other than my
head).
I find the apparent necessity of conflating syntax and semantics irksome,
i'd much rather that there be two
On Dec 21, 2010, at 5:00 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no coercion of any non-object. The reason
As a question how do soft fields/private names interact with an object that has
had preventExtensions called on it?
Are they entirely independent of normal property rules?
--Oliver
On Dec 23, 2010, at 3:57 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:51, Allen Wirfs-Brock wrote:
I
On Feb 9, 2011, at 12:35 AM, Peter van der Zee wrote:
Fwiw I don't recall any specific cases of input accepted by browsers which
shouldn't parse according to the spec, other than functions in statements.
Even callable regular expressions are fine as far as the grammar goes. I
don't have
This behaviour seems to result in undesirable behaviour in conjunction with
object literals:
Object.defineProperty(Object.prototype, foo, {value:bar});
use strict; var someObject = {foo:wibble}
Will now throw.
--Oliver
On Feb 16, 2011, at 6:02 PM, Allen Wirfs-Brock wrote:
They can be
I don't think generating 16bit values is beneficial -- either 8bit values for
byte at a time processing or full [u]int32 makes more sense. I think the only
reason for 16bit to come up is ecmascript's notionally 16bit characters.
I would prefer polymorphism of some form, for example
any
Implicit function calls within string formatting operations seem like the sort
of concept that is likely to lead to security problems on websites and the like.
This isn't a matter of can the engine do this safely it's a question of
whether the author expects arbitrary code execution to occur
I believe the current hope is to kill off __proto__ as quickly as is possible.
I'm not taking a position in this argument, this is just my current
understanding.
That said your examples environments that support it is slightly misleading as
there's only a few JS engines being used between
with a modified prototype
chain.
--Oliver
On Mar 18, 2011, at 10:41 AM, Boris Zbarsky wrote:
On 3/18/11 1:33 PM, Oliver Hunt wrote:
It also extends trivially to non-es objects, eg. Object.subclass(Image) or
somesuch in the DOM, etc.
Note that currently WebIDL calls for that to not work (in the sense
On Mar 20, 2011, at 6:53 PM, David Herman wrote:
typically this is seen as a quality of implementation issue. Note the we
(and most other language specs.) don't say much (or anything) about GC in
general. In one sense we don't need to say anything else about WeakMaps
because it would be
On Mar 23, 2011, at 6:21 PM, Garrett Smith wrote:
The infinite recursion could be detected and reported early. Where
does that happen? Does any engine report early for infinite recursion?
Non-trivial infinite recursion can't be detected early, and it's the
non-trivial cases that people miss
It has recently been brought to my attention that a particular use case of JSON
serialisation is to include JSON serialised content directly into an HTML file
(inside a script tag). In this case in addition to the threat of strings being
terminated by a double quote there's also the potential
On Apr 14, 2011, at 5:19 PM, Brendan Eich wrote:
On Apr 14, 2011, at 8:59 PM, P T Withington wrote:
On 2011-04-13, at 15:23, Brendan Eich wrote:
in my view, the operator is not ?. (i.e. a question followed by a
dot), but still just ?. The following dot is already about property
An implementation _could_ add a mode (*shudder*) along the same lines as strict
mode:
die in hell ASI, i hate you with the fiery passion of a thousand burning
suns.;
And then make it a syntax error whenever ASI would occur. I have considered
this in JSC (albeit with a slightly shorter opt in
Implementation specific -- JSC Function.prototype.toString returns the exact
input string for the body of the function.
--Oliver
On Apr 17, 2011, at 5:09 PM, Garrett Smith wrote:
On 4/17/11, Mikeal Rogers mikeal.rog...@gmail.com wrote:
do modern javascript implementations actually insert
On May 7, 2011, at 10:24 AM, Cedric Vivier wrote:
2. Would it be possible for Object.prototype.* to be read-only for
ES-Harmony (or even just strict mode)?
3. By read-only, I mean that changes to it would just silently be discarded.
Alternatively (especially for strict mode), warnings/errors
On May 10, 2011, at 10:16 AM, Andreas Rossberg wrote:
I'm a bit puzzled regarding the meaning of use strict in the context
of higher-order uses of eval.
Consider the following program. What is the expected result of the latter
calls?
-
var x = 3
function
As much as I'm opposed to the idea of keyword shortening for the sake of
keyword shortening, the more i think about it, the less i like the arrow syntax.
I think I'd simply prefer a prefix character to the infix arrow operator,
mostly from a readability stand point but i have a few other issues
On May 11, 2011, at 12:55 AM, Erik Corry wrote:
2011/5/10 Oliver Hunt oli...@apple.com:
As much as I'm opposed to the idea of keyword shortening for the sake of
keyword shortening, the more i think about it, the less i like the arrow
syntax.
I think I'd simply prefer a prefix character
On May 11, 2011, at 12:38 PM, David Bruant wrote:
Le 11/05/2011 20:38, felix a écrit :
On Wed, May 11, 2011 at 11:16, David Bruant david.bru...@labri.fr wrote:
A memoizer could be written to improve f time performance (by the cost of
memory, of course).
function memoizer(f){
var
On May 11, 2011, at 12:54 PM, Brendan Eich wrote:
On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
So you want to do
if (map.has(bar))
wiffle = map.get(bar)
or some such?
The problem here is that you can't guarantee that GC won't happen between
those two calls, and therefore you
The more I read the WeakMap spec, the more it seems to prevent the common use
cases I know of. Could someone give a few examples of problems the current
weakmap spec solves?
--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
, 2011, at 3:25 PM, Andreas Gal wrote:
Can you describe those common use cases, and how they are impossible with the
current specification?
Andreas
On May 14, 2011, at 3:05 PM, Oliver Hunt wrote:
The more I read the WeakMap spec, the more it seems to prevent the common
use cases I
Don't mind me, I misread the spec (again) as saying that if either the key or
value was live then the entire mapping remained alive.
--Oliver
On May 14, 2011, at 3:37 PM, Oliver Hunt wrote:
It's not that they're impossible, it's that they all reduce to a strong map
with automatic deletion
it
is a WeakMap.
--Oliver
On May 14, 2011, at 3:48 PM, Oliver Hunt wrote:
Don't mind me, I misread the spec (again) as saying that if either the key or
value was live then the entire mapping remained alive.
--Oliver
On May 14, 2011, at 3:37 PM, Oliver Hunt wrote:
It's not that they're impossible
:
On Sat, May 14, 2011 at 4:21 PM, Oliver Hunt oli...@apple.com wrote:
On May 14, 2011, at 4:03 PM, David Bruant wrote:
Le 15/05/2011 01:01, Oliver Hunt a écrit :
No, I am wrong, if i have a key that i can ever reuse, the map is strong,
because the key will keep the value live. These aren't
On May 15, 2011, at 3:47 PM, Boris Zbarsky wrote:
On 5/15/11 2:20 PM, Rick Waldron wrote:
Thanks Brendan, I was looking for something that was representative of
Boris's use-case
A typical example is an extension wanting to associate some state with a DOM
element or a Window without
On May 16, 2011, at 11:30 AM, Erik Corry wrote:
2011/5/16 Andreas Gal g...@mozilla.com:
Even if you want to store weak-map specific meta data per object, nobody
would store that directly in the object. Thats needlessly cruel on the cache
since 99.9% of objects never end up in a weak map.
On May 16, 2011, at 1:07 PM, Brendan Eich wrote:
WeakMaps satisfy this more general non-enumerable object-keyed cache use-case
well, too -- at least as far as I can tell. We'll be building on the Firefox
nightly implementation to find out more.
I think my problem with this is that WeakMap
IIRC I was saying that the engine should simply allow non-objects types to pass
through uncoerced, rather than taking any particular stance on ease of
implementation. I suspect in JSC that we would be able to do it without too
much difficulty, but there's a a world of difference between that,
I'm answering some of the performance questions in this, but i don't know what
the intended semantics of 'dynamic super' would be so I can't give specific
details of most of the use cases. If it's essentially sugar for super.foo =
Object.getPrototypeOf(this).foo (with appropriate munging for
On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote:
On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote:
On Jul 5, 2011, at 9:00 PM, David Herman wrote:
Mainstream production JS engines have moved away from parser generators.
Right, indeed most (all but JavaScriptCore, IINM) never used a
On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote:
On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote:
On Jul 5, 2011, at 9:00 PM, David Herman wrote:
Mainstream production JS engines have moved away from parser generators.
Right, indeed most (all but JavaScriptCore, IINM) never used a
This is all the stuff that will almost certainly require separate
implementations from the engine's core parser. And maybe
that's fine. In my case, I wanted to implement a reflection of
our existing parser, because it's guaranteed to track the
behavior of SpiderMonkey's parser.
CC'ing Gavin as he's been looking at RegExp compatibility in the real world vs.
the spec recently.
--Oliver
On Jul 7, 2011, at 12:17 PM, Mike Samuel wrote:
2011/7/7 Lasse Reichstein reichsteinatw...@gmail.com:
On Thu, Jul 7, 2011 at 3:52 AM, Mike Samuel mikesam...@gmail.com wrote:
On Aug 4, 2011, at 2:29 PM, Brendan Eich wrote:
1. return allowed from constructor?
...
Consensus is: RESOLVED, return disallowed from class constructor body.
What about return with no value -- there are cases where such early returns are
useful, and you would not be allowed to specify your
On Aug 4, 2011, at 6:45 PM, Brendan Eich wrote:
On Aug 4, 2011, at 3:15 PM, Oliver Hunt wrote:
On Aug 4, 2011, at 2:29 PM, Brendan Eich wrote:
1. return allowed from constructor?
...
Consensus is: RESOLVED, return disallowed from class constructor body.
What about return with no value
On Aug 17, 2011, at 6:52 AM, John-David Dalton wrote:
Awesome! That was our conclusion too. It was late Kit and I missed
trying it in other implementations (instead we dug into spec because
we thought it was odd). It turns out V8 (Chrome, Node.js) has a bug
that will make non-enumerable
On Aug 27, 2011, at 2:42 PM, Dmitry Soshnikov wrote:
On Sat, Aug 27, 2011 at 11:53 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
No. It's the global object what is the base (more precisely, its DOM's
proxy wrapper -- `window` or either the global itself), but not an
On Sep 2, 2011, at 3:41 PM, Brendan Eich wrote:
On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote:
On Friday, 2011-09-02 at 22:28 , Brendan Eich wrote:
Can you show your label hack for SpiderMonkey to es-discuss?
Ahh sorry I did not realized I forgot to post link:
On Sep 27, 2011, at 10:30 PM, Brendan Eich wrote:
On Sep 27, 2011, at 4:06 PM, Waldemar Horwat wrote:
Trying to understand Oliver's objections to the current class proposal.
Oliver objects, as do others, to punning (my word) declarative syntax to
define object properties, and mixing
On Sep 29, 2011, at 7:52 AM, Brendan Eich wrote:
On Sep 29, 2011, at 3:20 PM, Russell Leggett wrote:
On Wed, Sep 28, 2011 at 10:40 PM, Oliver Hunt oli...@apple.com wrote:
Given our apparent desire to have a declarative syntax i don't see why
something akin to:
Hi, just a voice from
1 - 100 of 253 matches
Mail list logo
