Re: How can a lexer decide a token to be get, IdentifierName or Identifier ?
Though it's a little too long since this discussion, I've tried Allen's
idea in my parser and still find conflicting.
Consider the following rules:
PropertyAssignment :
IdentifierName PropertyName ( ) { FunctionBody }
PropertyAssignment :
PropertyName : AssignmentExpression
PropertyName :
IdentifierName
when a parser get “IdentifierName” it need to decide reduce
the IdentifierName into get or “PropertyName”. For LR parsers there is no
way to do these things.
I would suggest another way:
IdentifierName ::
FutureReservedWord
Keywords
Identifier
SpecialWord
SpecialWord ::
get
set
2012/5/3 Allen Wirfs-Brock al...@wirfs-brock.com
If I was going to move something to the syntactic grammar it would
probably be the current definition of Identifier
Identifier :
IdentifierName but not ReservedWord
You might then lex all IdentifierNames (including ReservedWord) as
IdentifierName tokens and treat all occurrences of keyword terminals in the
syntactic grammar as short-hands for saying: IdentifierName matching this
specific keyword. For example:
PropertyAssignment :
get PropertyName ( ) { FunctionBody }
could be interpreted as:
PropertyAssignment :
IdentifierName PropertyName ( ) { FunctionBody }
with the static semantic restriction that the text of IdentifierName must
be get
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: thoughts the (re)organization of the specification?
Looks good. Have you considered to split this spec into two part: one is for language implementer and the other is for language user? 2012/11/3 Allen Wirfs-Brock al...@wirfs-brock.com In both ES5 and ES6 (so far) we have generally tried to maintain the section structure of the previous editions. Occasionally we have had to do some minor subsection renumbering (or not so minor in the case of ES5 section 10) but have generally maintained the overall structure of the entire document, even when it has appeared to non-optimial or even confusing. I'm now looking at the work to implement the refactoring of the internal methods in section 8 and I see we are probably going to loose even more of the section number correspondence with previous editions. This tempts me to seize the moment, abandon the legacy organization, and reorganize in a more logical manner. Here is the new structure that I have in mind, with reference to existing ES5 (section numbers:) Introductory Material Scope (1) Conformance (2) Normative References (3) Overview (4) Notational Conventions(5) The ECMAScript Computational Engine Data Types and Values (8) Commonly used Abstract Operations (9) ECMAScript Execution (10 and possibly parts of 14) [Possibly new material related to module loaders and realms] The ECMAScript Programming Language Source Text (6) Conformance, Error Handling, and Extensions (16) Lexical Tokens (7) Expressions (11) Statements (12) Functions and Classes (13) Scripts and Modules (14) The ECMAScript Standard Library (15) [potentially some reordering and reorganization] Annexes What thoughts do people have about this? Should we go for an improved document organization or should be continue to patch around the current structure, probably forever. If we do restructure, I would probably do most of the work after we were feature complete and until them, only make incremental changes that make sense that the context of new feature work. But it would be helpful to decide soon which path we are going to take. One of the issue is the correspondence between the spec. organization and the test262 organization. We already have massive changes changes and the algorithm and algorithm set level that will impact test232, so I'm not sure that the higher level reorg that I'm thinking about would have that much more impact on it. Feedback??? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Feed back and proposal for modules: allow importing ES5 files
Import is currently used by Module. This way of using import looks like a
loader feature.
2012/9/26 Russell Leggett russell.legg...@gmail.com
On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 csf...@gmail.com wrote:
Thanks, Claus and Alex,
I've looked at the Loader but it seems to be async?
I know there are many ways to load multiple files together(iframe, XHR,
script element and datauri for browser host) but what I'm suggesting is to
make es6 module more friendly to es5 libraries.
I mean currently the es6 module grammar is using
export var a;
var b;
var c;
But why not export all top-level scope variables and let developers use
IFFE to hide variables?
var a; // export a automatically
void function(){
var b;
var c;
}();
This will make libraries like old versions of jQuery work with es6 module
without any code change. These libraries might be on CDN and changing their
code will be a big cost in some scenarios.
Why not simply the proposal a little. It would be nice to be able to
export top level etc. but I think there is a clear danger there. What if
instead of trying to make arbitrary scripts into modules, we just did the
loading, making sure the script was loaded before running the code that
depended on it. ES5 relies on global scope, and so would this. Instead of
allowing:
import jQuery1.3.2.js,MyModule.js as MyModule;
Maybe just allow something like:
import jQuery1.3.2.js
import MyModule.js
$(..).attr(..)
Those scripts would still be executed in the global scope, and so this
module would be able to access $. It would be extremely easy to wrap this
way as well. Otherwise, you'd still need to worry about actually loading
the dependency, no?
- Russ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Feed back and proposal for modules: allow importing ES5 files
So what I've got is we need static meta data for Module exports. For this
reason export keyword is needed.
I was considering if these meta data could be given by the user of Module
(instead of author of Module).
If module file could only be used in ES6 (on need lexical convertion), I
thinking most guys are not going to use this feature with in a very long
time after ES6 released.
These days I'm thinking about simply use proposal 2.(Allow importing
multiple files as one module)
We could easily make a wrapper for ES5 libs。
---
// jQueryWrapper.js
export var $;
---
---
//in ***.html
import jQueryWrapper.js,jQuery.js as jQuery;
jQuery.$
---
What do you think?
2012/9/26 Claus Reinke claus.rei...@talk21.com
I've looked at the Loader but it seems to be async?
So far, yes, but previous discussions here led to the conclusion
that making the Loader functionality available for module syntax
imports would be useful and unproblematic. See, for instance,
the final paragraph of
https://mail.mozilla.org/**pipermail/es-discuss/2012-**July/024184.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2012-July/024184.html
Perhaps that hasn't been worked into the spec yet. I hope it
doesn't get lost.
I know there are many ways to load multiple files together(iframe,
XHR, script element and datauri for browser host) but what I'm
suggesting is to make es6 module more friendly to es5 libraries.
At first, a standard Loader plugin for treating ES5 scripts as modules
sounds useful, instead of everyone writing their own. Especially if a
generic script-as-modules-wrapper requires code analysis to figure
out global assignments.
That, however, is exactly the issue: ES5 scripts are not friendly to
ES6 modularity, as all export information is encoded dynamically -
one cannot figure out the exports without running the code.
So a general ES5-scripts-as-modules seems unlikely, and even
if one wanted to write converters for each currently encoded
module system, one would run into the runtime-vs-static issue,
unless all modules happen to use a static subset of current
module libraries (most module interface code will be static
in intention, if not in expression, but there are no guarantees).
Which is why I was referring to the RequireJS approach of
encoding the expected exports in the wrapper configuration.
Translating that to ES6 should be possible: we'd not even try
to extract the global assignments from the code automatically;
instead we'd tell the module wrapper manually how to extract
the expected exports from whatever the ES5 module code does
to its environment, by appending export declarations to the ES5
code. At least, that is how I understand this approach;-)
Claus
I mean currently the es6 module grammar is using
export var a;
var b;
var c;
But why not export all top-level scope variables and let developers use
IFFE to hide variables?
var a; // export a automatically
void function(){
var b;
var c;
}();
This will make libraries like old versions of jQuery work with es6 module
without any code change. These libraries might be on CDN and changing
their
code will be a big cost in some scenarios.
2012/9/24 Alex Russell a...@dojotoolkit.org
I think module loaders would, indeed help, although as you point out,
you're gonna need some sort of transformation step and we don't provide
an
AST to work against. You might need something like Traceur's front-end or
esprima to get started on a reliable transform pass. But yeah, doable.
On Mon, Sep 24, 2012 at 4:08 PM, Claus Reinke claus.rei...@talk21.com*
*wrote:
Right. What I'm suggesting isn't that you'll be able to prevent the
global
from being augmented, rather that if your goal is to take an *already
well
behaved* library and wrap it with modules, that's possible.
Aren't Module Loader Translation hooks meant to help with this?
http://wiki.ecmascript.org/doku.php?id=harmony:module_**http://wiki.ecmascript.org/**doku.php?id=harmony:module_**
loaders#translation_semantics**http://wiki.ecmascript.org/**
doku.php?id=harmony:module_**loaders#translation_semanticshttp://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#translation_semantics
Naïve idea: fetch the code, then add exports before evaluating the
code as a local module scope.
Though this would require parameterizing the Loader with some
configuration data (export $ from jquery, export {f,g,x} from
anotherES5utils, ..). Which seems to call for interaction between
fetch and translate hooks, and possibly even between import
declarations and loader hooks (how does the loader hook get
to know which exports to add to an ES5 script, for a given import
declaration?).
RequireJS has some experience with wrapping non-modules
via configuration options.
Re: Feed back and proposal for modules: allow importing ES5 files
Thank you for replying, Alex.
Replied inline.
2012/9/24 Alex Russell a...@dojotoolkit.org:
Hi Shaofei:
On Sep 22, 2012, at 6:29 PM, 程劭非 csf...@gmail.com wrote:
Hi, everyone,
I noticed that current importing grammar will not work for ES5 files,
I mean there is no way to import one or more es5/es3 files as a module
and import variables from it.
The problem is:
1. There are no export keywords in a es5/es3 file, no variables are
exported.
2. They might be using more than one files but current mudule grammar
allows only one file as one module.
When the new standard(es6) comes out, I guess a big number of
libraries need updating. And before they finish their work, I think we
need a cheap solution for the new code(es6) to use old
libraries(es5/es3) without modifying their code
One option here is for you to create an export wrapper for them, in essence
a separate file that requires the old library be loaded which then exports
the library's symbols through an export. Not pretty, but it requires no code
changes for well-designed libraries.
I tried to find a way to make a wrapper but I failed.
Consider I have a file
// mylib.js
//depends on jQuery
$(..).attr(..)
When importing it as a library
//There is no way to add $ to it's scope
//except polluting the global object
import mylib.js as myLib;
For the two points, I was considering two solution:
1. Export all global variable by default.
Anonymous function could be used to protect the global namespace and
most libraries are already using it. So I don't think export is
needed.
You inadvertently identified why we need exports: it's very difficult what
is global. In particular, what should be exported in the case of a file
that includes:
var f = function(param) {
thinger = param;
};
// ...
if (someGlobalConfigurationSetting) {
f(howdy!);
}
?
Exporting all global variable will not pollute the module's user's
namespace for we still need import phase.
Perhaps instead of global you mean the top-level IFFE?
In that case, it's easier, but then it depends on the IFFE both being
executed (it's not a static form here) and there being only one. Or is the
suggestion that a file like this should export both a and b? And what will
the value of c be?
// example.js
(function(p){
var a = p;
})(hello);
(function(p){
var b = p;
})(world);
var setValue = function(p){
var c = p;
};
setValue(it's a sunny day!);
setValue(it's raining in London);
// end example.js
As you can see, at the limit, this creates some serious hazards for violating
the data-hiding provided by closure-bound variables. Suddenly importers can
not only see these internal names, but watch their values change!
Perhaps I'm not expressing clearly.(Sorry I'm not a native speaker.)
I'm not saying that we should export variables inside a IFFE.
I mean that :
//example.js
var $;
// for ES5 $ should be a property of global object,
//I mean even without “export”, Module instance object
//should have a binding for $ when example.js imported
//as a Module
(function(){
$ = function(){
}
// $ could be changed
var $2 = function(){
}
// $2 will not be imported
// because it's in a IFFE.
})();
-
// somewhere
// Variant A:
import example.js as myQuery;
import $ from myQuery;
// Variant B:
module myQuery = bar.js;
import $ from myQuery;
//$ should be able to be used here
2. Allow importing multiple files as one module.
This will completely decouple file and module. We need to modify the
ModuleSpecifier grammar:
ModuleSpecifier ::= StringLiteral | Path
===
ModuleSpecifier ::= ( StringLiteral | Path ) ( , StringLiteral | Path )*
With this, for example, if I'm using a RSA library like
http://www-cs-students.stanford.edu/~tjw/jsbn/, I can do the
following:
import jsbn.js,prng4.js,rng.js,rsa.js as RSA;
If I want to use a module depend on jQuery1.3.2, I can do:
import jQuery1.3.2.js,MyModule.js as MyModule;
I've mentioned this idea in a reply, post it as a separate thread to
get more feed back :-)
This is interesting. Do you have a proposed resolution mechanism for
conflicts? We had such a thing in the old traits system for classes, but I
don't think it has survived anywhere.
Do you mean name conflict?
If jQuery1.3.2.js and MyModule.js are all ES5 style (no module
system used). There should not be any conficts or they will not work
in ES5.
This is different from
import jQuery1.3.2.js as jQuery;
import MyModule.js as MyModule;
The declaration
import jQuery1.3.2.js,MyModule.js as MyModule;
should behave like importing a file just like jQuery1.3.2.js and
MyModule.js are copied together.
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
___
es-discuss mailing list
es-discuss@mozilla.org
Feed back and proposal for modules: allow importing ES5 files
Hi, everyone, I noticed that current importing grammar will not work for ES5 files, I mean there is no way to import one or more es5/es3 files as a module and import variables from it. The problem is: 1. There are no export keywords in a es5/es3 file, no variables are exported. 2. They might be using more than one files but current mudule grammar allows only one file as one module. When the new standard(es6) comes out, I guess a big number of libraries need updating. And before they finish their work, I think we need a cheap solution for the new code(es6) to use old libraries(es5/es3) without modifying their code For the two points, I was considering two solution: 1. Export all global variable by default. Anonymous function could be used to protect the global namespace and most libraries are already using it. So I don't think export is needed. Exporting all global variable will not pollute the module's user's namespace for we still need import phase. 2. Allow importing multiple files as one module. This will completely decouple file and module. We need to modify the ModuleSpecifier grammar: ModuleSpecifier ::= StringLiteral | Path === ModuleSpecifier ::= ( StringLiteral | Path ) ( , StringLiteral | Path )* With this, for example, if I'm using a RSA library like http://www-cs-students.stanford.edu/~tjw/jsbn/, I can do the following: import jsbn.js,prng4.js,rng.js,rsa.js as RSA; If I want to use a module depend on jQuery1.3.2, I can do: import jQuery1.3.2.js,MyModule.js as MyModule; I've mentioned this idea in a reply, post it as a separate thread to get more feed back :-) /Shaofei Cheng ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: export questions
I guess Kevin has some same concerns with me. The four things point to one question: What should we do with the old ES3/ES5 libraries after we have module? (please correct me if you didn't mean that.) ES3/ES5 libraries might be in more than one files and there are no “export” and import in it. For example, I might want to use jQuery 1.3.2 in ES6, and I might could not modify the .js file for some reason. I might want the following thing: - import http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js; as jQuery var $ = jQuery.$; - And, a library might have dependencies, and they might not be using ES6 modules to manage their dependencies, I might want the following thing: - import jquery.min.js, MyES5Module.js as MyES5Module var dosth = MyES5Module.dosth; - Currently harmony:modules might not strong enough to cover these cases. My proposal is : 1. Export every thing by default. Since we have import ... from ... to protect our namespace there is no need to use “export”. If any author of library would like to hide local variable they will use anonymous function. 2.Allow multiple files in a module in Variant A: import URL syntax ModuleImport ::= StringLiteral as Id === ModuleImport ::= StringLiteral (, StringLiteral)* as Id 2012/8/29 Kevin Smith khs4...@gmail.com: Four things: 1) The export grammar on the wiki allows: export *; Which I take to mean export every local binding. What's the justification? I don't think I've ever seen a ES5 module that didn't have some local, non-exported state or function. 2) The grammar also allows: export * from Path.To.Module; which is fine. But I think it would also be convenient to provide the following: export * from SomeModule.js; In particular, this form would be useful in package main files, where you are combining the interface of several sub-modules into a single package interface. Using only the allowed forms, we would need something like: import SomeModule.js as SomeModule; export * from SomeModule; 3) I really like the module syntax (except for import *), and I would like to see convergence on the syntax for importing to a module instance: import SomeModule.js as SomeModule; // or module SomeModule = SomeModule.js; I personally like the former, but has there been any agreement on either one? Until there's a decision, we can't proceed with bleeding-edge transcompilation. : ) 4) Just a comment: the main argument in favor of import * is convenience. But it's nearly as convenient to import to a module instance: import A.js as A; A.x(); A.y(); This is indeed what Node.js programmers are used to and I don't believe there has been any gnashing of teeth over it. In my opinion, being able to statically analyze a module in isolation outweighs the additional convenience of import *. Thanks for your time! Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: export questions
What does it look like if you want to import more than one variables
from one module?
2012/8/31 Shijun He hax@gmail.com:
On Fri, Aug 31, 2012 at 3:16 PM, 程劭非 csf...@gmail.com wrote:
I guess Kevin has some same concerns with me.
The four things point to one question: What should we do with the old
ES3/ES5 libraries after we have module?
(please correct me if you didn't mean that.)
ES3/ES5 libraries might be in more than one files and there are no
“export” and import in it.
For example, I might want to use jQuery 1.3.2 in ES6, and I might
could not modify the .js file for some reason.
I might want the following thing:
-
import http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js;
as jQuery
var $ = jQuery.$;
-
I'm using this pattern from 2006:
$import(jquery.min.js#jQuery,$)
translate to ES6 syntax:
import {$} from jquery.min.js#jQuery
That is, use URI fragment to identify the export names for old scripts.
The loader will run the scripts in a sandbox and only export the
specified names.
This can be achieved in customized loader in current draft.
var myLoader = new Loader(System, {
translate: function(src, relURL, baseURL, resolved) {
var frag = new URL(relURL).fragment // URL class parse the url
to uri components
if (frag == null) return src
var exportNames = src.split(/\s*,\s*/)
return wrap(src, exportNames) // wrap the src with AMD-style
function wrapper
}
})
But maybe System loader could support it directly.
And, a library might have dependencies, and they might not be using
ES6 modules to manage their dependencies, I might want the following
thing:
-
import jquery.min.js, MyES5Module.js as MyES5Module
var dosth = MyES5Module.dosth;
-
Currently harmony:modules might not strong enough to cover these
cases. My proposal is :
1. Export every thing by default.
Since we have import ... from ... to protect our namespace there is
no need to use “export”. If any author of library would like to hide
local variable they will use anonymous function.
2.Allow multiple files in a module
in Variant A: import URL syntax
ModuleImport ::= StringLiteral as Id
===
ModuleImport ::= StringLiteral (, StringLiteral)* as Id
2012/8/29 Kevin Smith khs4...@gmail.com:
Four things:
1) The export grammar on the wiki allows:
export *;
Which I take to mean export every local binding. What's the
justification? I don't think I've ever seen a ES5 module that didn't have
some local, non-exported state or function.
2) The grammar also allows:
export * from Path.To.Module;
which is fine. But I think it would also be convenient to provide the
following:
export * from SomeModule.js;
In particular, this form would be useful in package main files, where you
are combining the interface of several sub-modules into a single package
interface. Using only the allowed forms, we would need something like:
import SomeModule.js as SomeModule;
export * from SomeModule;
3) I really like the module syntax (except for import *), and I would like
to see convergence on the syntax for importing to a module instance:
import SomeModule.js as SomeModule; // or
module SomeModule = SomeModule.js;
I personally like the former, but has there been any agreement on either
one? Until there's a decision, we can't proceed with bleeding-edge
transcompilation. : )
4) Just a comment: the main argument in favor of import * is
convenience. But it's nearly as convenient to import to a module instance:
import A.js as A;
A.x();
A.y();
This is indeed what Node.js programmers are used to and I don't believe
there has been any gnashing of teeth over it. In my opinion, being able to
statically analyze a module in isolation outweighs the additional
convenience of import *.
Thanks for your time!
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
Yes, as a developer (but not English native speaker), I really feel uncomfortable with the name “of”. Considering we already have Object.create String.fromCharCode To keep align with them, I belive “create” or “fromElements” might be better choices. 2012/8/27 Shijun He hax@gmail.com: See the screenshots for the array of search suggestion in search engine. As a non-English native speaker, I'd like to say the search suggestion of array of in non-english languages seems most come from the programmers' input, so it shows how worldwide programmers think what array of means ;) On Mon, Aug 27, 2012 at 10:55 AM, Matthew Robb matthewwr...@gmail.com wrote: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r...@gmail.com wrote: On Sunday, August 26, 2012 at 7:30 PM, Brendan Eich wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property name. It's darn nice for Rubyists. OTOH Array.of matches the preposition pattern used in Array.from. But I don't think this trumps Array.new. Nor do I, but I think it poses a problem for polyfilling (which is not a silver bullet). +1 Array.new, but I still think Array.of sounds, feels and looks nicer Rick Cc'ing Dave for his thoughts. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
Yes, as a developer (but not English native speaker), I really feel uncomfortable with the name “of”. Considering we already have Object.create String.fromCharCode To keep align with them, I belive “create” or “fromElements” might be better choices. 2012/8/27 Shijun He hax@gmail.com: See the screenshots for the array of search suggestion in search engine. As a non-English native speaker, I'd like to say the search suggestion of array of in non-english languages seems most come from the programmers' input, so it shows how worldwide programmers think what array of means ;) On Mon, Aug 27, 2012 at 10:55 AM, Matthew Robb matthewwr...@gmail.com wrote: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r...@gmail.com wrote: On Sunday, August 26, 2012 at 7:30 PM, Brendan Eich wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property name. It's darn nice for Rubyists. OTOH Array.of matches the preposition pattern used in Array.from. But I don't think this trumps Array.new. Nor do I, but I think it poses a problem for polyfilling (which is not a silver bullet). +1 Array.new, but I still think Array.of sounds, feels and looks nicer Rick Cc'ing Dave for his thoughts. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
consider adding more [no LineTerminator here] to avoid problem caused by omit the semicolon
Hi, everyone,
During some recent discussion in Chinese JS community, I've noticed
several case which JS behave out of user's expect if omitting the
semicolon.
See the following code:
var a = this.a // here no semicolon will be auto inserted
[1,2,3].forEach(function(){
// do something
})
(function(){
//do something
})() // here no semicolon will be auto inserted
(function(){
//do something else
})()
I was thinking that if we could change some grammar rules to make it
behave as most user's expect. Just adding several [no LineTerminator
here] will do so:
CallExpression :
MemberExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] [ Expression ]
CallExpression . IdentifierName
Though some of you might consider omitting the semicolon as a bad
style, but its used by several group and company （including zepto.js
and npmjs）. I think this change will benefit them a lot with very
small side effect.
/Shaofei
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
I guess we can try to push Web IDL to do this.
2012/6/11 Hemanth H.M hemanth...@gmail.com:
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like
an [] ?
--
'I am what I am because of who we all are'
h3manth.com
-- Hemanth HM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
How can a lexer decide a token to be get, IdentifierName or Identifier ?
Hi, everyone I noticed both “IdentifierName” and “Identifier” appeared in syntactical grammar of ES5. It seems a lexer will not be able to decide a token to be an IdentifierName or Identifier during lexing phase. A similar problem is “get”. get is not a keyword but is used like a keyword in object literal. It can also be used as an IdentifierName or Identifier. To solve the above issues, I guess we can treat IdentifierName as a syntactical symbol instead of a token type, using the following production: IdentifierName :: Identifier Keywords FutureReservedWord /Shaofei Cheng ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UUIDs?
UUID is not only a random Number or String. It has to contain time and position to make itself unique in the world. It looks Math.random is related to time. We have no way to involve position information to JS currently. 2012/3/16 Nuno Job nunojobpi...@gmail.com: Wrong list, sorry about that :) On Thu, Mar 15, 2012 at 4:34 PM, Nuno Job nunojobpi...@gmail.com wrote: (~~(Math.random() * 1e9)).toString(36) + Date.now(); On Thu, Mar 15, 2012 at 4:33 PM, Rick Waldron waldron.r...@gmail.com wrote: Axel, Have you ever seen this? http://www.broofa.com/2008/09/javascript-uuid-function/ I've been using this for several years Rick On Thu, Mar 1, 2012 at 5:45 PM, Axel Rauschmayer a...@rauschma.de wrote: UUIDs are useful for many tasks. One cannot create good ones in JavaScript without browsers exposing more of the underlying platform. Would it make sense to add UUID generation to ECMAScript.next? Or is that something for a browser API? Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UUIDs?
Random number in big enough range could replace uuid in most cases. But it's still not truely unique. In specified time and specified position(specified device), you can make sure there is only one uuid generated. BTW, we are using crypto.getRandomValues in our project, it works well until now. But I think it would be better if we have native uuid in JS. 2012/3/23 Mark S. Miller erig...@google.com: What does time or position have to do with uniqueness? Why not velocity, spin and charm? Seriously, given a good source of entropy, a large enough random number is globally unique. Math.random() is not a good source of entropy, but crypto.getRandomValues is. See http://wiki.whatwg.org/wiki/Crypto. On Thu, Mar 22, 2012 at 3:30 AM, 程劭非 csf...@gmail.com wrote: UUID is not only a random Number or String. It has to contain time and position to make itself unique in the world. It looks Math.random is related to time. We have no way to involve position information to JS currently. 2012/3/16 Nuno Job nunojobpi...@gmail.com: Wrong list, sorry about that :) On Thu, Mar 15, 2012 at 4:34 PM, Nuno Job nunojobpi...@gmail.com wrote: (~~(Math.random() * 1e9)).toString(36) + Date.now(); On Thu, Mar 15, 2012 at 4:33 PM, Rick Waldron waldron.r...@gmail.com wrote: Axel, Have you ever seen this? http://www.broofa.com/2008/09/javascript-uuid-function/ I've been using this for several years Rick On Thu, Mar 1, 2012 at 5:45 PM, Axel Rauschmayer a...@rauschma.de wrote: UUIDs are useful for many tasks. One cannot create good ones in JavaScript without browsers exposing more of the underlying platform. Would it make sense to add UUID generation to ECMAScript.next? Or is that something for a browser API? Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The name and length property of JSON.parse and JSON.stringify
Thank you. It's my fault that I didn't read it carefully. 2012/3/12 Lasse Reichstein reichsteinatw...@gmail.com On Mon, Mar 12, 2012 at 8:33 AM, 程劭非 csf...@gmail.com wrote: Hi all, Just noticed that there is no description about name and length property of JSON.parse and JSON.stringify in ES5. Are they implement-dependent? (I saw test262 require JSON.stringify.length to be 3, but no such case for JSON.parse. ) The first part of section 15 says: Every built-in Function object described in this clause―whether as a constructor, an ordinary function, or both―has a length property whose value is an integer. Unless otherwise specified, this value is equal to the largest number of named arguments shown in the subclause headings for the function description, including optional parameters. I.e., the lengths are specified. I don't believe the name properties for function objects are specified anywhere in ES5, so they are entirely outside the spec. /L ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The result of (0).toExponential(1)
I don't think so. ES5 specified the algorithm of toExponential. “The number is the same” is not the only requirement. See the algorithm below: ( please pay attention to 8.a ) 1. Let *x* be this Number value http://es5.github.com/#this-Number-value. 2. Let *f* be ToInteger http://es5.github.com/#x9.4(*fractionDigits*). 3. If *x* is *NaN*, return the String *NaN*. 4. Let *s* be the empty String. 5. If *x* ** 0, then 1. Let *s* be *-*. 2. Let *x* = �C*x*. 6. If *x* = +∞, then 1. Return the concatenation of the Strings *s* and *Infinity*. 7. If *fractionDigits* is not *undefined* and (*f* 0 or *f* 20), throw a *RangeError http://es5.github.com/#x15.11.6.2* exception. 8. If *x* = 0, then 1. *Let f = 0.* 2. Let *m* be the String consisting of *f*+1 occurrences of the character ‘0’. 3. Let *e* = 0. 9. Else, *x* ≠ 0 1. If fractionDigits is not *undefined*, then 1. Let *e* and *n* be integers such that 10*f* ≤ *n* 10*f*+1 and for which the exact mathematical value of *n* × 10*e*�C*f* �C *x* is as close to zero as possible. If there are two such sets of *e* and *n*, pick the *e* and *n* for which *n* × 10*e*�C*f* is larger. 2. Else, *fractionDigits* is *undefined* 1. Let *e*, *n*, and *f* be integers such that *f* ≥ 0, 10*f* ≤ *n* 10*f*+1, the number value for n× 10*e*�C*f* is *x*, and *f* is as small as possible. Note that the decimal representation of*n* has * f*+1 digits, *n* is not divisible by 10, and the least significant digit of *n* is not necessarily uniquely determined by these criteria. 3. Let *m* be the String consisting of the digits of the decimal representation of *n* (in order, with no leading zeroes). 10. If *f* ≠ 0, then 1. Let *a* be the first character of *m*, and let *b* be the remaining *f * characters of *m*. 2. Let *m* be the concatenation of the three Strings *a*, *.*, and *b*. 11. If *e* = 0, then 1. Let *c* = *+.* 2. Let *d* = *0.* 12. Else 1. If *e* 0, then let *c* = *+.* 2. Else, *e* ≤ 0 1. Let *c* = *-*. 2. Let *e* = �C*e*. 3. Let *d* be the String consisting of the digits of the decimal representation of *e* (in order, with no leading zeroes). 13. Let *m* be the concatenation of the four Strings *m*, *e*, *c*, and *d* . 14. Return the concatenation of the Strings *s* and *m*. According to this algorithm, (0).toExponential(1) should return 0e+0.(f is set to 0) But it looks none of V8, spidermonkey and JScript did that thing. Their result is 0.0e+0. So is there anyone could give some message about why does ES5 define this behavior like this? Or is it simply a spec bug? 2012/3/8 Jens Nockert j...@nockert.se On H.24/03/08, at 12:39, DX Jin dox@gmail.com wrote: (0).toExponential(1) should, according to the algorithm in 15.7.4.6, return 0e+0. But all browser implementations return 0.0e+0 instead. Which is wrong? The specification or the implementations? Neither, the result is correct. The number is the same, just different representations as strings. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
I prefer this to be root object. Some object could have more than one
ancestor.
2012/3/6 Aymeric Vitte vitteayme...@gmail.com
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined in specs to
access properties of objects but nothing the other way, because I believe
the case never happens today.
The this proposal is not bad for me (and even good), if I take Lasse
Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b; this.b = this.a}; var g
= new f();//g.a undefined //g.b undefined
It does not solve your issue but it makes me think to a more global issue,
the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or this post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html(which
apparently did not passionate)
But this should not be applicable to functions only, this could be
generalized to objects, where this unless explicitely bound to something
should refer to the object itself, and not the global object (moreover that
there are discussions about the future of the global object)
Then an Object.GetBase could be added to refer to the parent or outer
object
I am not aware of all discussions (maybe it was already discussed and
rejected) and it's not easy to see the whole impact of such change, but I
don't think that the idea is absurd, I did not invent it myself and it
would be more logical than the current behavior of this and avoid
repetitives operations (var self=this, getters/setters, use of new (why do
I have to use new in the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, 程劭非 a écrit :
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard to
implement it in my library.
But I guess the problem is we have no way to refer to its parent. Do you
have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com
It's a shame that this doesn't work with object literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing
listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Sorry.
I mean the following case:
var x = {
a:{
},
b:{
}
}
x.a.p = x.b.p = {};
So GetBase is not able to decide to return x.a or x.b.
在 2012年3月6日 下午11:08，Aymeric Vitte vitteayme...@gmail.com写道：
Some object could have more than one ancestor.
Yes, so ? It's not in contradiction with what I am saying
Le 06/03/2012 14:58, 程劭非 a écrit :
I prefer this to be root object. Some object could have more than one
ancestor.
2012/3/6 Aymeric Vitte vitteayme...@gmail.com
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined in specs to
access properties of objects but nothing the other way, because I believe
the case never happens today.
The this proposal is not bad for me (and even good), if I take Lasse
Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b; this.b = this.a}; var
g = new f();//g.a undefined //g.b undefined
It does not solve your issue but it makes me think to a more global
issue, the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or this post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html(which
apparently did not passionate)
But this should not be applicable to functions only, this could be
generalized to objects, where this unless explicitely bound to something
should refer to the object itself, and not the global object (moreover that
there are discussions about the future of the global object)
Then an Object.GetBase could be added to refer to the parent or outer
object
I am not aware of all discussions (maybe it was already discussed and
rejected) and it's not easy to see the whole impact of such change, but I
don't think that the idea is absurd, I did not invent it myself and it
would be more logical than the current behavior of this and avoid
repetitives operations (var self=this, getters/setters, use of new (why do
I have to use new in the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, 程劭非 a écrit :
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard to
implement it in my library.
But I guess the problem is we have no way to refer to its parent. Do you
have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com
It's a shame that this doesn't work with object literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing
listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
That will work in json but Object.GetBase is not so nice.
Also I think GetBase(GetBase(GetBase(this))) looks a bit ugly.
在 2012年3月7日 上午12:22，Aymeric Vitte vitteayme...@gmail.com写道：
Even if GetBase was existing I don't know if it would cover all your
needs but unless I missed something I don't get your last example (where p
is defined and where GetBase is supposed to be called ?)
Le 06/03/2012 16:33, 程劭非 a écrit :
Sorry.
I mean the following case:
var x = {
a:{
},
b:{
}
}
x.a.p = x.b.p = {};
So GetBase is not able to decide to return x.a or x.b.
在 2012年3月6日 下午11:08，Aymeric Vitte vitteayme...@gmail.com写 道：
Some object could have more than one ancestor.
Yes, so ? It's not in contradiction with what I am saying
Le 06/03/2012 14:58, 程劭非 a écrit :
I prefer this to be root object. Some object could have more than one
ancestor.
2012/3/6 Aymeric Vitte vitteayme...@gmail.com
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined in specs
to access properties of objects but nothing the other way, because I
believe the case never happens today.
The this proposal is not bad for me (and even good), if I take Lasse
Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b; this.b = this.a}; var
g = new f();//g.a undefined //g.b undefined
It does not solve your issue but it makes me think to a more global
issue, the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or this post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html(which
apparently did not passionate)
But this should not be applicable to functions only, this could be
generalized to objects, where this unless explicitely bound to something
should refer to the object itself, and not the global object (moreover that
there are discussions about the future of the global object)
Then an Object.GetBase could be added to refer to the parent or outer
object
I am not aware of all discussions (maybe it was already discussed and
rejected) and it's not easy to see the whole impact of such change, but I
don't think that the idea is absurd, I did not invent it myself and it
would be more logical than the current behavior of this and avoid
repetitives operations (var self=this, getters/setters, use of new (why do
I have to use new in the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, 程劭非 a écrit :
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard to
implement it in my library.
But I guess the problem is we have no way to refer to its parent. Do you
have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com
It's a shame that this doesn't work with object literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing
listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Consider extending JSON grammar to support objects with circular reference
Hi, everyone,
As you know, JSON API will throw a syntax error when trying to stringify a
object with circular reference.But indeed the feature
serializing/unserializing object with circular reference is needed.(eg.
when storing a graph,or status machine)
I am working on a JS implement of parse/stringify to support a “path
grammar” in JSON. It looks like the following:
// this will produce a object with it's property “x” reference to it self
{
x:path(/)
}
//also relative path is supported
{
x:{
a:path(../x),
b:path(x)
}
}
//ref to deeper object
{
x:{
a:{
obj:[]
},
b:path(/x/a/obj)
}
}
// path could also point to a none-object value
{
a:11,
b:path(/a)
}
// path ref to a path node will get undefined, there is no way to recurse
{
a:path(/), //the root object
b:path(/a) //undefined
}
--
( The project is located at https://github.com/wintercn/JSONplus
. in which JSON.pareseEx and JSON.stringifyEx passes all test262 API
cases except the ones related to circular reference. )
I was wondering if the future version of ECMAScript could support this
grammar or something like this to enable serializing/unserializing object
with circular reference. It will be a good news for ones working on complex
data structure.
PS. Another known way of descripting object with circular reference is
using sharp
variablehttps://developer.mozilla.org/en/Sharp_variables_in_JavaScript
in
object literal . But there are several problems:
1. The id in sharp variable has to be unique. Combining two objects with
conflicted ids will be hard work.
2. Sharp variable is sensitive to the order of object properties. A
assignment must appear before its first usage. But path do not have such
requirement.Since the order of properties defined in JSON would
(especially) affect enumerate (for.. in) order, making a order-independent
reference grammar is a must.
3. Sharp variable requires assignment operator, and hence assignment
expression and even continuous assignment expression. Adding this feature
to JSON increases the complexity of its grammar a lot.
Thanks,
Shaofei Cheng
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
JSON.stringfyEx will never produce text like this but JSON.parseEx accept
this form.
I mean
{
a:11,
b:path(/a)
}
will act all the same with
{
a:11,
b:11
}
2012/3/5 Marius Gundersen gunder...@gmail.com
// path could also point to a none-object value
{
a:11,
b:path(/a)
}
How would you build this from a JavaScript object? There is (so far) no
way to have a reference to a none-object value, so there would be no way to
construct this json object from a JavaScript object, and no way to
recontstruct a JavaScript object from this json string. Therefore paths
should only be able to refer to objects or arrays.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
I mean in the following case
{
{
a:p(/)
}
}
“this” will not be powerful enough to describe it.
2012/3/5 gaz Heyes gazhe...@gmail.com
On 5 March 2012 12:16, 程劭非 csf...@gmail.com wrote:
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard to
implement it in my library.
But I guess the problem is we have no way to refer to its parent. Do you
have any ideas?
You could have something like this:
{
a:123,
b: function circular() { return this.a; }
}
and then obj.b(); would result in 123
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
{
a: path(/a2), // yes, path(/a2) is a object
a2: {c: 1, d: path(../b/d)}, // no, path(/b) is a path itself you will
get undefined here.
b: path(/b2), //yes, path(/b2) is a object
b2: {c: path(../a/c), d: 2}, // no path(../a) is a path itself you will
get undefined here.
}
In general, I mean a path will never refer to a object specified by a path.
2012/3/5 Andreas Rossberg rossb...@google.com
On 5 March 2012 13:20, 程劭非 csf...@gmail.com wrote:
JSON.stringfyEx will never produce text like this but JSON.parseEx accept
this form.
I mean
{
a:11,
b:path(/a)
}
will act all the same with
{
a:11,
b:11
}
Do you expect
{
a: path(a2),
a2: {c: 1, d: path(../b/d)},
b: path(b2),
b2: {c: path(../a/c), d: 2},
}
to work? Even ignoring the issue with circularities, you would need to
do (deep) dependency analysis before initialising individual
properties.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
So it would produce copies of literals, but references of objects/arrays?
Yes, it would.
and could be parsed so adding a member to either obj.b or ob.a would
update the other one. This would therefore be more powerfull than simply
copying the same values to the different names when parsing.
I don't quite sure about what do you mean by “update”. obj.a and obj.b
should be the same object. There are no third object in this case.
Consider the following code:
var obj = JSON.parseEx( {\
\b\: {},\
\a\: path(/b)\
} );
obj.a===obj.b would be true. They are the same object.
2012/3/5 Marius Gundersen gunder...@gmail.com
JSON.stringfyEx will never produce text like this but JSON.parseEx accept
this form.
I mean
{
a:11,
b:path(/a)
}
will act all the same with
{
a:11,
b:11
}
So it would produce copies of literals, but references of objects/arrays?
For example:
var obj = {};
obj.b = {};
obj.a = obj.b;
Would produce:
{
b: {},
a: path(/b)
}
and could be parsed so adding a member to either obj.b or ob.a would
update the other one. This would therefore be more powerfull than simply
copying the same values to the different names when parsing.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
No, not that hard.
When I find a path node what I need to do is only:
set the value if the node already exists,
create a listener if the node doesn't exist.
When creating a property node(for object) or element node(for array), I
just check if there is a listener to this node.
2012/3/5 Andreas Rossberg rossb...@google.com
On 5 March 2012 13:35, 程劭非 csf...@gmail.com wrote:
{
a: path(/a2), // yes, path(/a2) is a object
a2: {c: 1, d: path(../b/d)}, // no, path(/b) is a path itself you
will
get undefined here.
b: path(/b2), //yes, path(/b2) is a object
b2: {c: path(../a/c), d: 2}, // no path(../a) is a path itself you
will
get undefined here.
}
In general, I mean a path will never refer to a object specified by a
path.
Why? And anyway, what about:
{
a: {c: 1, d: path(../b/d)},
b: {c: path(../a/c), d: 2},
}
You still need deep dependency analysis.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Thanks. I have mentioned it in my first email. :)
2012/3/5 Wes Garland w...@page.ca
Mozilla used to support something like this, it is being removed in
Firefox 12, but perhaps the implementation can give you ideas.
https://developer.mozilla.org/en/Sharp_variables_in_JavaScript
Wes
On 5 March 2012 07:49, Andreas Rossberg rossb...@google.com wrote:
On 5 March 2012 13:35, 程劭非 csf...@gmail.com wrote:
{
a: path(/a2), // yes, path(/a2) is a object
a2: {c: 1, d: path(../b/d)}, // no, path(/b) is a path itself you
will
get undefined here.
b: path(/b2), //yes, path(/b2) is a object
b2: {c: path(../a/c), d: 2}, // no path(../a) is a path itself you
will
get undefined here.
}
In general, I mean a path will never refer to a object specified by a
path.
Why? And anyway, what about:
{
a: {c: 1, d: path(../b/d)},
b: {c: path(../a/c), d: 2},
}
You still need deep dependency analysis.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
You are right, Allen. I didn't mean to modify JSON itself. And as Lasse
Reichstein said above, JSON is not controled by this group at all.
I am just thinking we need a way to serialize/unserialize a js object with
circular reference to itself.
Obviously JSON can not handle it currently. It might be
Object.serialize/Object.unserialize or JSON.parseJSONP or what ever. I'm
OK with any form of APIs.
在 2012年3月6日 上午12:53，Allen Wirfs-Brock al...@wirfs-brock.com写道：
Let's get back to some key mainly non-technical points.
JSON is a data interchange format that was created to support data
interchange between heterogeneous systems, not just JavaScript.
TC39 does not define the actual JSON encoding format. If we extend it, it
is no longer JSON.
There are many domain specific applications of the JSON format. These
typically make use of a data schema defined (either formally or informally)
over the JSON format.
One domain specific application is serialization (for storage or
transport) of arbitrary JavaScript object graphs. Many of us have defined
either special case or general purpose JSON schemas for doing this. Many
people have also done so for other languages.
Designing a JS object graph serialization schema for JSON is not the same
thing as extending JSON.
If anybody thinks they have the ultimate JS serialization schema, publish
it as a library and try to get people to use it. If it gets broad adoption
and there is a major benefit that would come from it being an integral
part of the language standard, come on back and talk to TC-39.
Finally, I'm not saying there are no circumstances under which we should
consider extending the ES JSON support. For example, I think we should
consider adding JSON.parseJSONP as a function. JSONP has broad adoption and
there would be a major security benefit from safely parsing it at the ES
engine level.
Allen
On Mar 5, 2012, at 4:59 AM, 程劭非 wrote:
Thanks. I have mentioned it in my first email. :)
2012/3/5 Wes Garland w...@page.ca
Mozilla used to support something like this, it is being removed in
Firefox 12, but perhaps the implementation can give you ideas.
https://developer.mozilla.org/en/Sharp_variables_in_JavaScript
Wes
On 5 March 2012 07:49, Andreas Rossberg rossb...@google.com wrote:
On 5 March 2012 13:35, 程劭非 csf...@gmail.com wrote:
{
a: path(/a2), // yes, path(/a2) is a object
a2: {c: 1, d: path(../b/d)}, // no, path(/b) is a path itself you
will
get undefined here.
b: path(/b2), //yes, path(/b2) is a object
b2: {c: path(../a/c), d: 2}, // no path(../a) is a path itself you
will
get undefined here.
}
In general, I mean a path will never refer to a object specified by a
path.
Why? And anyway, what about:
{
a: {c: 1, d: path(../b/d)},
b: {c: path(../a/c), d: 2},
}
You still need deep dependency analysis.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should Literal in syntactical grammar instead of lexical grammar?
Thank you for the comments. There might be no normative significance but I mean there is no way to put the Literal production in a lexer. If a lexer produce token with type ”Literal“, syntactical parser will not be able to decide to use it as a ”Literal“ or a ”StringLiteral“. So I think keeping this rule in current location might confuse the ones who want to implement this spec. Thanks, Shaofei Cheng 2012/2/28 Brendan Eich bren...@mozilla.org Indeed this has come up before: https://mail.mozilla.org/**pipermail/es5-discuss/2011-** January/003900.htmlhttps://mail.mozilla.org/pipermail/es5-discuss/2011-January/003900.html No one replied then, alas. There's no normative significance, as Michael Dyck conjectured. It seems we could move Literal. Perhaps Waldemar or Allen has a preference. At this point I am ok with letting the traditional location of Literal stand. /be 程劭非 wrote: Hi, everyone, I'm working a on ES parser recently and noticed something might be wrong about the symbol “Literal”. Since “Literal” and “StringLiteral NumericLiteral appears in lexical grammar , I believe “Literal” should be a non-terminal symbol. Also there is no other rule using “Literal” in lexical grammar. As all above I think the following description is a syntactical grammar rule instead of a lexical grammar rule: /Literal /*:: ***/NullLiteral/ /BooleanLiteral NumericLiteral StringLiteral/ /RegularExpressionLiteral/ So my suggest is moving the description from Annex A.1 to Annex A.3 Thanks, Shaofei Cheng __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should Literal in syntactical grammar instead of lexical grammar?
Thank you, Allen. I've checked ES6 draft and reported a bug. see https://bugs.ecmascript.org/show_bug.cgi?id=281 2012/2/29 Allen Wirfs-Brock al...@wirfs-brock.com Yes, Literal could be moved to the syntactic grammar. There is already some grammar refactoring like this going on in the Es6 draft. The best way to capture these sorts of editorial issues is to file a bug using bugs.ecmascript.org against the current Es6 draft. Allen On Feb 28, 2012, at 2:50 AM, Brendan Eich wrote: Indeed this has come up before: https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003900.html No one replied then, alas. There's no normative significance, as Michael Dyck conjectured. It seems we could move Literal. Perhaps Waldemar or Allen has a preference. At this point I am ok with letting the traditional location of Literal stand. /be 程劭非 wrote: Hi, everyone, I'm working a on ES parser recently and noticed something might be wrong about the symbol “Literal”. Since “Literal” and “StringLiteral NumericLiteral appears in lexical grammar , I believe “Literal” should be a non-terminal symbol. Also there is no other rule using “Literal” in lexical grammar. As all above I think the following description is a syntactical grammar rule instead of a lexical grammar rule: /Literal /*:: ***/NullLiteral/ /BooleanLiteral NumericLiteral StringLiteral/ /RegularExpressionLiteral/ So my suggest is moving the description from Annex A.1 to Annex A.3 Thanks, Shaofei Cheng ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Should Literal in syntactical grammar instead of lexical grammar?
Hi, everyone, I'm working a on ES parser recently and noticed something might be wrong about the symbol “Literal”. Since “Literal” and “StringLiteral NumericLiteral appears in lexical grammar , I believe “Literal” should be a non-terminal symbol. Also there is no other rule using “Literal” in lexical grammar. As all above I think the following description is a syntactical grammar rule instead of a lexical grammar rule: *Literal **:: ****NullLiteral* *BooleanLiteral NumericLiteral StringLiteral* *RegularExpressionLiteral* So my suggest is moving the description from Annex A.1 to Annex A.3 Thanks, Shaofei Cheng ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
