Right, I think "mixin" is winning over "define" as the name. Same semantics
in either case.
Allen
On Feb 5, 2013, at 9:03 AM, Rick Waldron wrote:
>
>
>
> On Tue, Feb 5, 2013 at 11:55 AM, Brandon Benvie
> wrote:
> Indeed, and given use of ES6, I expect things like this wouldn't be very
>
On Tue, Feb 5, 2013 at 11:55 AM, Brandon Benvie
wrote:
> Indeed, and given use of ES6, I expect things like this wouldn't be very
> uncommon (I think is supposed to be Object.define right?):
>
Nothing there yet, though I suspect Object.mixin() will have more traction.
https://mail.mozilla.org/pi
Indeed, and given use of ES6, I expect things like this wouldn't be very
uncommon (I think is supposed to be Object.define right?):
Object.define(x, {
get a(){},
set a(v){},
get b(){},
c(){}
});
Instead of most current descriptor stuff (since enumerability and
configurability are rarely d
On Tue, Feb 5, 2013 at 3:19 AM, gaz Heyes wrote:
> On 4 February 2013 23:44, Brendan Eich wrote:
>
>> What's confusing?
>>
>
> The fact that you can have an object property without a colon and a
> function without a function keyword.
>
ES6 concise methods will make this the norm:
let o = {
m
On 4 February 2013 23:44, Brendan Eich wrote:
> What's confusing?
>
The fact that you can have an object property without a colon and a
function without a function keyword. Then a property descriptor uses a
completely new syntax to define the same thing. Why?
Object.defineProperty(window,'x',{se
gaz Heyes wrote:
I find the syntax of set/get confusing:
What's confusing?
({'get'x(){return 123;}}).x
That's not legal ES5.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 4 February 2013 21:56, Michael Dyck wrote:
> Brendan Eich wrote:
>
>>
>> Don't forget method definition shorthand syntax, if the next token is
>> "(". Then the method is named "get", of course.
>>
>
I find the syntax of set/get confusing:
({'get'x(){return 123;}}).x
___
Brendan Eich wrote:
Don't forget method definition shorthand syntax, if the next token is
"(". Then the method is named "get", of course.
Yup. Like I said, I was ignoring the effect of other productions.
(That's what the OP appeared to be doing too.)
-Michael
Michael Dyck wrote:
There's no way only if you're talking about an LR(0) parser. But an
LR(1) parser would have 1 token of lookahead to resolve the conflict:
-- if the next token is ":", reduce IdentifierName to PropertyName;
-- if the next token is an IdentifierName, shift that.
-- if the ne
程劭非 wrote:
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
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
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
SpiderMonkey, at least, uses feed-forward from parser to lexer, a
one-bit mode flag:
http://mxr.mozilla.org/mozilla-central/search?string=TSF_KEYWORD_IS_NAME
/be
程劭非 wrote:
Hi, everyone
I noticed both “IdentifierName” and “Identifier” appeared in
syntactical grammar of ES5. It seems a lexer
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
14 matches
Mail list logo
