From: Waldemar
Date: Thu, May 26, 2011 at 4:22 PM
Subject: May 24-26 rough meeting notes
>
> Guard Syntax:
> Technical aspects ok, but some are worried about the effects of this
> change on the ECMAScript style.
What aspects of ECMAScript style were cause for concern? Fear of Java?
> Cormac's s
On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan wrote:
> [documenting/expanding some ideas briefly discussed at today's meeting]
>
> The current proxy proposal has a method to create a new proxy:
>
> var proxy = Proxy.create(handler, proto);
>
> We could extend this proposal to allow an existing
[documenting/expanding some ideas briefly discussed at today's meeting]
The current proxy proposal has a method to create a new proxy:
var proxy = Proxy.create(handler, proto);
We could extend this proposal to allow an existing object to be
converted to a proxy, via:
var proxy = Proxy.createFro
On Thu, May 26, 2011 at 4:27 PM, Sean Eagan wrote:
> Something similar could work for properties, need to think about it.
Here's a start:
// reusable descriptor
var allFalse = {configurable: false, writable: false, enumerable: false};
var foo = {
{configurable: false} @ a: 1, // writable, enu
A whole bunch of agenda reordering
Test262 report slideshow
Debate about who should host the test262 website
Deferred discussion
[For the purposes of these notes, Harmony and ES.next are synonyms. We were
using "advanced to Harmony" to mean "advanced to ES.next".]
"RegExps match reality":
Wal
On Thu, May 26, 2011 at 2:57 PM, David Flanagan wrote:
> Is a not-quite-so-cryptic shorthand possible?
I tried to choose the characters to be as non-cryptic as possible
using the following mnemonic devices:
# - non-configurable:
corresponds to frozen which # represents for records, tuples etc.
On Thu, May 26, 2011 at 11:54 AM, Sean Eagan wrote:
> On Thu, May 26, 2011 at 1:43 PM, Mike Shaver wrote:
>> On Thu, May 26, 2011 at 11:37 AM, Sean Eagan wrote:
>>> // ! implies non-writable, ~ implies non-enumerable
>>> // all assignment operators can be used
>>> ! a.b += c
>>
>> Legal parse to
On 5/26/11 10:46 AM, David Bruant wrote:
Le 26/05/2011 18:44, David Flanagan a écrit :
I'd put that distinction in an abstract Proxy.Handler class and then
rename the current Proxy.Handler to Proxy.ForwardingHandler.
What do you call a "class" is is a constructor with some arguments?
Could you
On May 26, 2011, at 1:09 PM, Michael Haufe wrote:
> Is there any plan to standardize Sharp Variables or something similar?
>
> https://developer.mozilla.org/en/Sharp_variables_in_JavaScript
No plans. I tried in 1998 or 1999, when TC39 was doing ES3. Rok Yu, then of
Microsoft, argued against sta
Is there any plan to standardize Sharp Variables or something similar?
https://developer.mozilla.org/en/Sharp_variables_in_JavaScript
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Is a not-quite-so-cryptic shorthand possible? Could you use #readonly,
#hidden, and #fixed instead of !, ~ and #, for example? This would be
more extensible. Maybe #sealed and #frozen for object, literals?
David
On 5/26/11 11:37 AM, Sean Eagan wrote:
Note: This proposal stems from the
On Thu, May 26, 2011 at 1:54 PM, Sean Eagan wrote:
> PostfixExpression:
> BasicLeftHandSideExpression
Sorry, I meant:
PostfixExpression :
BasicLeftHandSideExpression
BasicLeftHandSideExpression [no LineTerminator here] ++
BasicLeftHandSideExpression [no LineTerminator here] --
Thanks,
S
2011/5/26 Waldemar :
> If unicode character u+1234 is an identifier character, then this is a
> substitution of a variable whose name is that one-letter identifier just
> like any other $foo substitution would be. If not, then this is the two
> characters $ and u+1234.
Good point about escape sequ
On Thu, May 26, 2011 at 1:43 PM, Mike Shaver wrote:
> On Thu, May 26, 2011 at 11:37 AM, Sean Eagan wrote:
>> // ! implies non-writable, ~ implies non-enumerable
>> // all assignment operators can be used
>> ! a.b += c
>
> Legal parse today, though I'm not sure you can get runtime semantics
> that
On Thu, May 26, 2011 at 11:37 AM, Sean Eagan wrote:
> // ! implies non-writable, ~ implies non-enumerable
> // all assignment operators can be used
> ! a.b += c
Legal parse today, though I'm not sure you can get runtime semantics
that aren't an error.
> !~a.b++
> !(~(a.b++))
Legal expressions t
Note: This proposal stems from the discussion in [3]. The intention
is to update [1] and [2] and either include the new content within [1]
or a new strawman linked to from [2].
Object.defineProperty shorthand
==
Object.defineProperty calls are verbose, and also require pr
On a somewhat related note, I recently noticed that the semantics of
[[GetProperty]] and [[GetOwnProperty]], according to
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics,
contain a possible "reject" step, which doesn't seem to be
well-defined given that these method have no Throw p
Le 26/05/2011 18:44, David Flanagan a écrit :
> On 5/26/11 6:51 AM, Sean Eagan wrote:
>> Is think it would beneficial to replace all this.* calls in the
>> default trap implementations with Object.* methods and syntax that
>> subsequently triggers the this.* calls. This would guarantee that
>> non
Le 26/05/2011 19:10, David Flanagan a écrit :
> On 5/26/11 9:35 AM, David Flanagan wrote:
>> On 5/26/11 6:36 AM, Tom Van Cutsem wrote:
>>> Hi David,
>>>
>>> The short answer: if you also define a 'set' trap, throwing a
>>> TypeError from defineProperty() to signal rejection is appropriate
>>
>> Tha
If unicode character u+1234 is an identifier character, then this is a
substitution of a variable whose name is that one-letter identifier just
like any other $foo substitution would be. If not, then this is the two
characters $ and u+1234.
On Wed, May 25, 2011 at 4:19 PM, Mike Samuel wrote:
> W
On 5/26/11 9:35 AM, David Flanagan wrote:
On 5/26/11 6:36 AM, Tom Van Cutsem wrote:
Hi David,
The short answer: if you also define a 'set' trap, throwing a
TypeError from defineProperty() to signal rejection is appropriate
Thanks. I was worried that defineProperty() was required to honor
p
On 5/26/11 6:51 AM, Sean Eagan wrote:
Is think it would beneficial to replace all this.* calls in the
default trap implementations with Object.* methods and syntax that
subsequently triggers the this.* calls. This would guarantee that
none of the internal object semantics are being missed, and
i
On 5/26/11 6:36 AM, Tom Van Cutsem wrote:
Hi David,
The short answer: if you also define a 'set' trap, throwing a
TypeError from defineProperty() to signal rejection is appropriate
Thanks. I was worried that defineProperty() was required to honor
property changes since getOwnPropertyDescrip
Is think it would beneficial to replace all this.* calls in the
default trap implementations with Object.* methods and syntax that
subsequently triggers the this.* calls. This would guarantee that
none of the internal object semantics are being missed, and
implementations could still optimize just
Hi David,
The short answer: if you also define a 'set' trap, throwing a TypeError from
defineProperty() to signal rejection is appropriate.
The longer answer:
defineProperty() is based on [[DefineOwnProperty]] (ES5 section 8.12.9)
whose rejection behavior depends on an explicit 'Throw' parameter
I updated the quasis strawman (
http://wiki.ecmascript.org/doku.php?id=strawman:quasis ) to include
the suggested changes to escape sequence handling, and the
SubstitutionBody definition based on identifier chains:
${ident1.ident2}.
There was a very rough desugaring suggested to make raw literal
p
ECMAScript doesn't curry its function declarations. A function does take
all its arguments at once (and not as a tuple value), and since we can
even supply too few or too many arguments when calling a function, trying
to
mimic SML will only bring pain.
I thought so, too, for a long time. But
On Thu, 26 May 2011 07:15:31 +0200, David Griffiths
wrote:
Many, many languages (including Perl, Ruby, VB, Scala, Smalltalk,
Logo, and of course all the ML-like languages, including Haskell and
F#) do without parentheses for calls in some circumstances at least.
Do you use any of these langua
28 matches
Mail list logo
