On May 24, 2011, at 7:44 AM, Brendan Eich wrote:
> You're right, this would be unambiguous because a block can't initialize a
> var. The only interpretation is an expression, which with Allen's proposal
> combined with object intiialiser shorthand would parse {!b}.
One more thing: {b} in expres
On May 24, 2011, at 7:37 AM, Sean Eagan wrote:
> I am definitely a grammar classification noob, so feel free to rake me
> over the coals on this if necessary, but how is :
>
> var a = {!b};
>
> ... any more difficult to parse than ...
>
> var a = {b};
>
> ... both {b} and {!b} and valid blocks
On Tue, May 24, 2011 at 9:10 AM, Brendan Eich wrote:
> On May 24, 2011, at 7:02 AM, Sean Eagan wrote:
>
>>> This conflicts with the existing:
>>> var foo = "bar";
>>> {foo} // "bar"
>>> {!foo} // false
>>>
>>
>> No, just because |{!b}| is current syntax, doesn't mean that |var a = {!b}|
>> is.
>
On May 24, 2011, at 7:02 AM, Sean Eagan wrote:
>> This conflicts with the existing:
>> var foo = "bar";
>> {foo} // "bar"
>> {!foo} // false
>>
>
> No, just because |{!b}| is current syntax, doesn't mean that |var a = {!b}|
> is.
I've been working on syntax lately, and based on that work, I t
On Tue, May 24, 2011 at 9:02 AM, Sean Eagan wrote:
> // ->
>
> function A (){
> var a = arguments[0];
> Object.defineProperty(this, "b", {configurable: false, enumerable:
> false, writable: true, arguments[1]})
> Object.defineProperty(this, "c", {configurable: true, enumerable:
> true, writable
On Mon, May 23, 2011 at 4:44 PM, Rick Waldron wrote:
> Please excuse me, I'm just looking for clarification - thanks in advance:
>
>>
>> Also, the current infix writable mark does not compose with "Implicit
>> property initialization expressions" [1] as noted in [2]. Using a
>> prefix fixes this:
Please excuse me, I'm just looking for clarification - thanks in advance:
> Also, the current infix writable mark does not compose with "Implicit
> property initialization expressions" [1] as noted in [2]. Using a
> prefix fixes this:
>
> let a = {!b}
>
This conflicts with the existing:
var fo
ing, if
we provide sugar for initializing property descriptor attributes, we
should also provide it for modifying them or adding new properties as
that is likely just as common of a use case.
-Message d'origine- From: Sean Eagan
Sent: Saturday, May 21, 2011 10:10 AM
To: es-discuss
Subject:
ile less used pattern would get longer syntax).
>
I agree that we should be very careful when adding syntax sugar,
however there are clearly cases where it makes sense, and I think this
could be one of them. Also, I think it should be all or nothing, if
we provide sugar for initializing proper
oposals while less used pattern would get longer syntax).
-Message d'origine-
From: Sean Eagan
Sent: Saturday, May 21, 2011 10:10 AM
To: es-discuss
Subject: Proposal: Concise instance initialisation
Summary:
Update "Object Literal Extensions" [1] to integrate with cons
Summary:
Update "Object Literal Extensions" [1] to integrate with constructor
parameters for concise instance initialization.
Details:
function f (a, !~this.b, this.c:= 1) {
g(a);
}
// results in f's [[Construct]] ( but not [[Call]] ) behaving like:
function f (a, b, c = 1) {
Object.define
11 matches
Mail list logo
