The JSON RFC says
The names within an object SHOULD be unique.
Sadly, there are people in the JavaScript community who interpreted SHOULD to
mean DON'T HAVE TO. In a perfect world, we would change the SHOULD to MUST, but
we can't. Interoperability and security concerns demand that we
On 6/6/2013 4:34 AM, Anne van Kesteren wrote:
On Thu, Jun 6, 2013 at 12:29 PM, Douglas Crockford
doug...@crockford.com wrote:
The JSON RFC says
The names within an object SHOULD be unique.
Sadly, there are people in the JavaScript community who interpreted SHOULD
to mean DON'T HAVE
On 6/6/2013 5:00 AM, gaz Heyes wrote:
On 6 June 2013 12:29, Douglas Crockford doug...@crockford.com
mailto:doug...@crockford.com wrote:
The JSON RFC says
The names within an object SHOULD be unique.
Sadly, there are people in the JavaScript community who
interpreted
On 2012-11-18 10:49 PM, Brendan Eich wrote:
Brendan Eich wrote:
I agree that * or other operators should not be naively supported on
arrays, which are not value objects in any case. Any vector or matrix
value object would want sweet literal syntax, but it wouldn't be array
literal syntax,
On 2012-09-27 9:19 AM, Allen Wirfs-Brock wrote:
Consider
function f(a, b= a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39 meeting
this will display:
3 1 3
Any disagreement of this?
A constantly
On 2012-09-17 10:04 PM, Brendan Eich wrote:
Moral of this story: avoid United.
/be
I have had similar experiences on Alaska, Delta, and long, long ago on
Amtrak. The moral is more complicated than that.
There may be an important meta-moral here.
On 8/8/2012 11:40 AM, Brendan Eich wrote:
To be fair, the issue is not overridng own read-only or setter-based
properties. It is overriding delegated properties.
But there too one can argue, and extant code wants (see WebIDL),
assignment-invoking-a-setter to abstract over prototype delegation.
On 8/8/2012 5:01 PM, Brendan Eich wrote:
:= is only the latest in a line of proposals for solutions.
Please excuse my confusion. For some reason I expected := to be like an
assignment operator.
___
es-discuss mailing list
es-discuss@mozilla.org
On 4/24/2012 1:28 PM, Brendan Eich wrote:
http://www.imdb.com/title/tt0076759/quotes?qt=qt0440727
http://www.imdb.com/title/tt0121766/quotes?qt=qt0333083
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 4/2/2012 8:24 AM, Brendan Eich wrote:
Jorge wrote:
I saw it
here:http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this
Right -- I think Doug was remembering the Harmony of My Dreams
sharp-functions
(http://brendaneich.com/2011/01/harmony-of-my-dreams/#sharp_functions),
but
On 11:59 AM, Waldemar Horwat wrote:
On 02/01/2012 11:35 AM, Allen Wirfs-Brock wrote:
Here's one which I couldn't express in a lexer grammar: How to restart
the quasi after an included expression is over.
If quasis are not nested, then the lexical rule is really simple: Just
match the `s, and
On 11:59 AM, Mark S. Miller wrote:
Note that I don't see any realistic way to fix problem #3 in the
ES.next language. My point is only that defensive programming is
tricky even after you've gotten all the formal properties you need. As
ES.next introduces various new abstraction mechanisms,
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of it
that way.
Syntax was the point, though, and productivity should be higher with
CoffeeScript provided the user learns it, all else equal.
Do we have any evidence of that? Is there
On 10/13/2011 10:05 AM, Russell Leggett wrote:
I don't think less typing results in better typing. As you've said,
typing is not the time killer. However, I think the argument could be
made that if people enjoy what they're doing more, they will be more
productive. This article
On 11:59 AM, John J Barton wrote:
GrawlixScript is the connection I guess.
No, grawlix is a term of art that can be used to describe some the
literal syntax proposals.
___
es-discuss mailing list
es-discuss@mozilla.org
On 11:59 AM, Waldemar Horwat wrote:
Thinking about the implications of paren-free, I see additional
potential trouble spots in addition to the one I mentioned in the
meeting yesterday:
Start with ES5 code:
if (a + b)
(x.y)()
z++
Now (erroneously) convert it to paren-free:
if a + b
On 11:59 AM, Felipe Gasper wrote:
Is it possible to get sorted keys:
{a:1,c:3}
…from running JSON.stringify when declaring an object thus:
{c:3,a:1}
JSON objects are unordered. If order is important, then use an array.
___
es-discuss mailing list
On 11:59 AM, Bob Nystrom wrote:
Haven't we done that with ES1-3 already? Users have had 15 years of
prototypes and what they chose to do was make classes. We've got
Closure's goog.extends(), Dojo's dojo.declare(), Prototype's
Class.create() (ironic, given the name of the framework!), JS.Class,
On 11:59 AM, Brendan Eich wrote:
We've been extending JS in SpiderMonkey forever. Had we not, it's hard
to say what would have happened. One anecote: getters and setters were
something I added over a decade ago, such that when Firefox took
enough share from IE that by 2005, the live.com
On 11:59 AM, Brendan Eich wrote:
But hey, if JS does not need to change then we can avoid trouble and
keep on using 16-bit indexing and length. Is this really the best outcome?
It may well be. The problem is largely theoretical, and the many offered
cures seem to be much worse than the disease.
On 11:59 AM, Allen Wirfs-Brock wrote:
class hierarchy diagrams are only useful for understanding designs when you
actually have complex hierarchies. This very conversation is about adding
features to make it easy for JS programmers to build such hierarchies. Who
knows, may e in a few years
On 5/11/2011 9:19 AM, Brendan Eich wrote:
I still think the completion value leak problem is manageable with
docs, tools, and resort to good old function long-hand syntax. Opinions?
We have observed that one of the world's best capability theorists and
practitioners, intending to to write solid
On 11:59 AM, Oliver Hunt wrote:
rant
It does annoy me that these were not made immutable. The safest way to create
an object is still either with an object literal or new SomeFunction;
I'm not convinced that Object.create added anything of value to the language,
and certainly wouldn't
On 11:59 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2011, at 6:14 AM, Kyle Simpson wrote:
Many JSON serializer implementations escape the / character, including for instance PHP's
json_encode(). However, JavaScript's own JSON.stringify() does not. If you look at the grammar on
json.org, as I
On 11:59 AM, P T Withington wrote:
ES3 does not have the luxury of Object.create,
Object.create is easily implemented with the ES3 language.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 11:59 AM, Brendan Eich wrote:
Really, it's starting to feel like Survivor or American Idol
around here. The apples to oranges death-matching has to stop.
I don't mind a good deathmatch as long as it ends in death.
We will soon be at the point where we need to start culling the strawmen
so
On 11:59 AM, Paul Biggar wrote:
In SpiderMonkey, we can very easily make Date.now() return fractional
bits, which allows sub-millisecond timing. I've been using this for a
few weeks, and it's been very useful for my small purposes (more
accurate benchmarks). We're now looking at making this a
On 11:59 AM, Oliver Hunt wrote:
I keep seeing code like this, I simply don't see it as viable to have
for (.. in ...) sometimes enumerate property names, and some times
enumerate keys, it seems like it could be both confusing and error
prone. esp. given the simplest example: [x for (value in
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 capability
test check? If all major browsers parse without
On 11:59 AM, Oliver Hunt wrote:
That said I think allowing '1.' (etc) makes sense as it's fairly standard
across multiple programming languages, and I am unaware of any specific reason
for disallowing it.
In the long term I don't see changing the grammar to allow a trailing period as
being
I would like to see the next edition of the specification use the
ECMAScript language to describe the ECMAScript language. I think this
would significantly improve the likelihood that a programmer could
correctly understand ECMAScript by reading the standard. I think that
would make the web a
On 11:59 AM, Brendan Eich wrote:
On Apr 29, 2010, at 4:33 PM, Mark S. Miller wrote:
On Thu, Apr 29, 2010 at 2:40 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
The JSConf audience poll did provoke someone to suggest fun,
and I mentioned fn (the ML family
Allen Wirfs-Brock wrote:
Regarding toJSON results:
I believe that the original intent from json2.js was that toJSON functions were
supposed to return primitive values. However, the formulation of the Str
algorithm in 15.12.3 pretty clearly allows for toJSON functions that return
objects.
In addition of code units in the range 0x-0x001f JSON.stringify inserts escape sequences into string literals for some or all of the following code units:
0x007f-0x009f, 0x00ad, 0x0600-0x0604,0x070f,0x17bf,0x17b5,0x200c-0x200f,0x2028-0x202f,0x2060-0x206f,0xfeff,0xfff0-0x
There is no
Oliver Hunt wrote:
The
specified behaviour of the abstract operation Quote in section 15.12.3
states that only characters with a unicode number less than or equal to
0x1f should be escaped. My testing found that json2.js escapes a number
of other ranges of characters in unicode:
Allen Wirfs-Brock wrote:
JSON.parse([010])
should be an error, per spec. Nobody follows the spec though...
As I read them neither the RFC or the current ES5 JSON grammar recognize [010] as a
valid JSON form, so according to the ES5 spec. a syntax error should be thrown. If we really want
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize?
No. An implementation has the license to support other formats (such as an
XML object or a SuperJSON object). But the JSON object should recognize only
the JSON forms described by ES5. There
Mark S. Miller wrote:
Crock, is your position that ES5 should specify a validating JSON
parse exactly equivalent to the parse specified in the RFC (i.e.,
waiving the escape clause), but with JSON value as the start symbol?
If so, then I agree.
Yes.
Mark S. Miller wrote:
Crock, is your position that ES5 should specify a validating JSON
parse exactly equivalent to the parse specified in the RFC (i.e.,
waiving the escape clause), but with JSON value as the start symbol?
If so, then I agree.
Yes. Then we are in agreement.
Waldemar Horwat wrote:
Here are my views on this.
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize? This probably could be done by extending
the syntax error extension allowance in section 16 to include the JSON
grammar. If we allow this
Waldemar Horwat wrote:
Douglas Crockford wrote:
Waldemar Horwat wrote:
2) Do we want to permit conforming implementations to extend the
JSON grammar that they recognize? This probably could be done by
extending the syntax error extension allowance in section 16 to
include the JSON grammar
Brendan Eich wrote:
On Mar 21, 2009, at 9:01 AM, Allen Wirfs-Brock wrote:
By breaking symmetry we have made at least one browser-based
implementation precedent (Rhino also supports reduce and reduceRight)
with no thisArg for the fold methods. At this point I would rather we
stand on
It occurs to me, that using arguments.callee is the only way
to express recursion within a function created using the Function
constructor and that use of the Function constructor (rather than
eval) should probably be encouraged for dynamically constructing
functions from source code.
-Original Message-
From: Douglas Crockford [mailto:doug...@crockford.com]
It is not the only way. You can write an annonymous function that
returns
a named, recursive function. So arguments.callee is not required for
that unlikely case.
Not exactly equivalent if you are using the function
Allen Wirfs-Brock wrote:
Unless others speak up, the path of least resistance is to use for both
unnamed function expressions and new Function as that language is already in the ES3.1
spec.
Bully!
___
Es-discuss mailing list
Es-discuss@mozilla.org
On Feb 20, 2009, at 3:26 PM, Mark S. Miller wrote:
2009/2/20 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com:
The cop-out is to just leave it as it is.
The safe decision is to mandate the current de facto standard.
The brave (ie, risky) decision for a better long term language is to
It was originally 10. John got it wrong in the ECMA announcement, which I asked
him to correct. Waldemar didn't see the correction.
It should be 10, but now Waldemar says we won't have a room until 11:30.
Mark S. Miller wrote:
Waldemar, Crock, I think you guys may have miscoordinated whether
Allen Wirfs-Brock wrote:
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
The use of \ slightly bothers me because it is takes a character
that now is exclusively used in the lexical (token) grammar
( Unicode escapes, string escapes, line continuations)
and gives it syntactic
Notes from the 2nd Meeting on Secure ECMAScript
November 18, 2008
SHEET ONE
Valija
String.prototype.foo = function () {
return this;
};
...
... zip.foo() ...
... zip.foo.call(zip) ...
Cajita
function re() {
use strict,cajita;
[strike]return
49 matches
Mail list logo
