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
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
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
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
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
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
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.
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
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
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
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
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
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
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 :)
.
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
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
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
: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
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
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.
在
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
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)
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
.
}
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
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
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
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
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
/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
程劭
.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
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
31 matches
Mail list logo
