Re: On revoking access to the target of a proxy
FYI, the ideas expressed in this thread are now written up as a strawman: http://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
I wrote up a strawman that summarizes the discussion on proxies private names in this thread: http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names There are still some open issues though. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem tomvc...@gmail.com wrote: I wrote up a strawman that summarizes the discussion on proxies private names in this thread: http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names There are still some open issues though. I like it! Seems to work pretty well, and the fact that it allows us to actually pass the private name itself around is very nice and simple. Changing to an unknownPrivateName() trap is interesting. It seems kinda weird to be a *trap*, rather than just a property on the handler object, though. Is there a good reason to have that be dynamic? ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
2012/9/18 Tab Atkins Jr. jackalm...@gmail.com Changing to an unknownPrivateName() trap is interesting. It seems kinda weird to be a *trap*, rather than just a property on the handler object, though. Is there a good reason to have that be dynamic? Well, you could indeed define it as a simple boolean-valued property (if a use case does require a dynamic check, it could still be implemented as an accessor). It's currently defined as a trap for general consistency (thus far, handlers define nothing but traps). Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
Le 18/09/2012 10:44, Tab Atkins Jr. a écrit :
On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
I wrote up a strawman that summarizes the discussion on proxies private
names in this thread:
http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names
There are still some open issues though.
I like it! Seems to work pretty well, and the fact that it allows us
to actually pass the private name itself around is very nice and
simple.
Changing to an unknownPrivateName() trap is interesting. It seems
kinda weird to be a *trap*, rather than just a property on the handler
object, though. Is there a good reason to have that be dynamic?
A proxy might want to throw on unknownPrivateNames for write traps, but
not read traps. As I'm writing that, I realize that I had suggested to
have the operation ('get', 'set', 'defineOwnProperty'...) as argument of
the unknownPrivateNames trap (but not the arguments of the operation
itself), but this isn't in the strawman.
That would be the only reason I see to have the unknownPrivateNames as a
trap.
Regarding resolvePrivateName+public part, the use case isn't clear. The
whitelist allows for proxies to expresse knowledge a dynamic set of
names, I don't really see how what more a resolve trap enables.
As said in the strawman, now that we have the whitelist, we can get rid
of the public part of private names, which is one less burden on the
shoulders of implementors.
In the worst case, if someone comes up with a use case that requires
unique names, a public part and additional argument to
unknownPrivateNames can be added in a later version of the spec.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Performance concern with let/const
On 17 September 2012 18:37, Luke Hoban lu...@microsoft.com wrote: 'let' is certainly not going to be faster than 'var' in any case There is at least one very important counterexample to that claim: the global scope. Assuming lexical global scope (as we tentatively agreed upon at the last meeting) using 'let' in global scope will be _significantly_ faster than 'var', without even requiring any cleverness from the VM. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Performance concern with let/const
On Sep 18, 2012, at 7:27 AM, Andreas Rossberg wrote:
On 17 September 2012 19:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 17, 2012, at 12:37 PM, Luke Hoban wrote:
These are good questions. Paul will be attending the TC39 meeting this
week, and can likely talk to specific details. High level though, we
statically eliminate the TDZ checks for references to 'let' within the same
closure body as the declaration.
The other major check that I would expect to be significant, is whether a
inner function that references an outer TDZ binding is (potentially) called
before initialization of the binding. EG:
{
function f(){return x}
f(); //TDZ check of x in f can not be eliminated
let x=1;
}
{
function f(){return x}
let x=1; //TDZ check of x in f should be eliminated
f();
}
Unfortunately, detecting this case in general requires significant
static analysis, since f might be called indirectly through other
functions (even ignoring the case where f is used in a first-class
manner).
Yes but but there are fairly simple heuristics that approximate that result,
for example:
if no function calls dominate the initialization of x then TDZ checks will
never need to be made for x
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: The joys of United flight 242
On 2012-09-17 10:04 PM, Brendan Eich wrote: Moral of this story: avoid United. /be I have had similar experiences on Alaska, Delta, and long, long ago on Amtrak. The moral is more complicated than that. There may be an important meta-moral here. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Performance concern with let/const
On 18 September 2012 13:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Yes but but there are fairly simple heuristics that approximate that result, for example: if no function calls dominate the initialization of x then TDZ checks will never need to be made for x Yes, except that in JS, a function call can hide behind so many seemingly innocent operations... /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Room/building number for the meeting?
For some reason I can't open document repository to look at the latest venue document. The last one I have says that the room is still unknown. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Some questions about Private Name Objects
I just spoke to Allen and need to make a correction the post above: computed properties were, in fact, later dropped. Rick On Fri, Sep 14, 2012 at 5:34 PM, Irakli Gozalishvili rfo...@gmail.comwrote: Hey Dean, I also really love clojure protocols and in fact tried to propose few extensions for private names to make them little more usable as such: https://mail.mozilla.org/pipermail/es-discuss/2012-June/023657.html https://gist.github.com/2967124 Unfortunately thread did not got any replies from anyone. That being said I did couple of experiments in these area: Implemented clojure like protocols as library: http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post But after using it for some time I realised it was not very javascripty, so I have prototyped a more minimalistic version, which I'm using happily since then: https://github.com/Gozala/method I still really wish we could make private names callable such that: var method = Name() method(object, arg1, arg2) = object[method](arg1, arg2) Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Thursday, 2012-09-13 at 14:46 , Dean Landolt wrote: The real point I'm trying to make is that Name objects give us something akin to clojure's protocols. Imagine an orm protocol -- this is just a set of names that must exist on an object (or its proto chain). An object can implement any number of protocols (or interfaces, or whatever) without fear of conflict. You can easily override any implementation so long as you have a handle on the appropriate name object. This is easier, better looking and more correct than anything we can do today. It's not too disimilar from using using instanceof as a brand, but without the pitfalls (it doesn't fall flat crossing sandbox boundaries). This is a safe and flexible inheritance model that works just as a js programmer would expect, all without begging for mutable or multiple prototypes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that emulate the syntaxFeature /* @endif */ */ There's probably an anwser to that question, it's just that I'm not aware of it already :-) -Message d'origine- From: Brendan Eich Sent: Tuesday, September 18, 2012 7:17 PM To: François REMY Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ; es-discuss@mozilla.org Subject: Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const) François REMY wrote: | But if we have macros, then many progressive | enhancement and anti-regressive polyfill approaches can be done, even | with new syntax (not just with APIs). Seems like another good way of fixing the issue :-) However, this seems to require some form of conditionnal compilation to work , right? [1] [1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml Macros have nothing to do with conditional compilation _per se_. When you read Macros in a JS context, don't think the C Pre-Processor, think Scheme! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
François REMY wrote: My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that emulate the syntaxFeature /* @endif */ */ There's probably an anwser to that question, it's just that I'm not aware of it already :-) Yes, polyfilling means has-syntax testing. I'm told the sweet.js project is considering how to do this, but I bet a donut that it'll not look like CPP or @-CPP or any such ugly blast from the past. More in a bit. /be -Message d'origine- From: Brendan Eich Sent: Tuesday, September 18, 2012 7:17 PM To: François REMY Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ; es-discuss@mozilla.org Subject: Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const) François REMY wrote: | But if we have macros, then many progressive | enhancement and anti-regressive polyfill approaches can be done, even | with new syntax (not just with APIs). Seems like another good way of fixing the issue :-) However, this seems to require some form of conditionnal compilation to work , right? [1] [1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml Macros have nothing to do with conditional compilation _per se_. When you read Macros in a JS context, don't think the C Pre-Processor, think Scheme! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)
It's still early to say. But my feeling is that if we can get macros working, we can introduce new syntax via modules, not just unconditionally throwing them in everywhere. Then you don't have to do these kinds of global conditional things; rather, you just import the syntax from modules. The dynamic testing would then be done during app setup, when you construct your global environment before running the client code that uses it. The goal of macros is to make syntax more modular. Dave On Sep 18, 2012, at 2:23 PM, Brendan Eich bren...@mozilla.com wrote: François REMY wrote: My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that emulate the syntaxFeature /* @endif */ */ There's probably an anwser to that question, it's just that I'm not aware of it already :-) Yes, polyfilling means has-syntax testing. I'm told the sweet.js project is considering how to do this, but I bet a donut that it'll not look like CPP or @-CPP or any such ugly blast from the past. More in a bit. /be -Message d'origine- From: Brendan Eich Sent: Tuesday, September 18, 2012 7:17 PM To: François REMY Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ; es-discuss@mozilla.org Subject: Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const) François REMY wrote: | But if we have macros, then many progressive | enhancement and anti-regressive polyfill approaches can be done, even | with new syntax (not just with APIs). Seems like another good way of fixing the issue :-) However, this seems to require some form of conditionnal compilation to work , right? [1] [1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml Macros have nothing to do with conditional compilation _per se_. When you read Macros in a JS context, don't think the C Pre-Processor, think Scheme! /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
Re: About bugfix: For ISO 8601 syntax, Date.parse should accept in places where T is allowed
Hi Colin,
When changing the implementation of a standard built-in function that's defined
in the ECMAScript Language Specification, you should always check the
specification:
http://ecma-international.org/ecma-262/5.1/
In this case, it seems your extension of the accepted formats is allowed by the
statement the function may fall back to any implementation-specific heuristics
or implementation-specific date formats.
http://ecma-international.org/ecma-262/5.1/#sec-15.9.4.2
Norbert
On Sep 17, 2012, at 0:53 , LittleQ wrote:
I made a patch for bug-791320 [1], and somebody ask me to get opinions from
this mailing list.
This patch added support for accepting in places where T is allowed
originally, will it cause any problem.
for example:
2012-12-12T12:12:12 and the derivation(append millisecond or timezone) will
be accepted.
2012-12-12 12:12:12 will be accepted after this patch
and these won't be accepted after this modifying:
2012-12-12A12:12:12 (A could be replaced by a-zA-Z)
2012-12-12-12:12:12
2012-12-12:12:12:12
any comment for this fixing?
Thanks, this is my first patch for firefox :) any advise will be welcome~
[1] For ISO 8601 syntax, Date.parse should accept in places where T is
allowed.: https://bugzilla.mozilla.org/show_bug.cgi?id=791320
--
{
greeting: Have a nice day!,
name: Colin Su,
nickname: LittleQ,
email: littleq0...@gmail.com,
website: http://about.me/littleq;,
title: [
[Genie Capital, Web Developer],
[National Chengchi University, Student, Computer Science Dept.]
]
}
___
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 bugfix: For ISO 8601 syntax, Date.parse should accept in places where T is allowed
This is the response I posted to the bugzilla issue:
I would like to see a better motivation present for why this change is
important. In particular, it is a deviation from the ECMAScript standard.
While syntactic extensions to the Date.parse syntax is allowed by the
specification. It is not particularly a good idea. In particular, every time
a specific implementation adds such a non-standard extension, it creates a
potential cross-browser interoperability hazard.
Apparently these extensions are not motivated by a desire to improve
interoperability as reference [1] shows that none of Firefox, IE, and Safari
currently provide these extensions. Chrome apparently does (and also Opera??).
Finally, I don't understand why a WhatWG document is being used to justify a
change to an ECMAScript specified function or why the WhatWG is messing with an
ECMA specification. If there is a serious proposal to change the ECMAScript
specification it should be brought to TC39 as a proposal where it would be
given serious consideration. But simply bypassing the standards process
doesn't seem like a very good idea. In particular, Google is a member of TC39
and Chrome has apparently implemented these extensions. Yet as far as I know,
they have not made a proposal for this extension to TC39. Why not?
Allen
On Sep 17, 2012, at 12:53 AM, LittleQ wrote:
I made a patch for bug-791320 [1], and somebody ask me to get opinions from
this mailing list.
This patch added support for accepting in places where T is allowed
originally, will it cause any problem.
for example:
2012-12-12T12:12:12 and the derivation(append millisecond or timezone) will
be accepted.
2012-12-12 12:12:12 will be accepted after this patch
and these won't be accepted after this modifying:
2012-12-12A12:12:12 (A could be replaced by a-zA-Z)
2012-12-12-12:12:12
2012-12-12:12:12:12
any comment for this fixing?
Thanks, this is my first patch for firefox :) any advise will be welcome~
[1] For ISO 8601 syntax, Date.parse should accept in places where T is
allowed.: https://bugzilla.mozilla.org/show_bug.cgi?id=791320
--
{
greeting: Have a nice day!,
name: Colin Su,
nickname: LittleQ,
email: littleq0...@gmail.com,
website: http://about.me/littleq;,
title: [
[Genie Capital, Web Developer],
[National Chengchi University, Student, Computer Science Dept.]
]
}
___
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 bugfix: For ISO 8601 syntax, Date.parse should accept in places where T is allowed
On Wed, Sep 19, 2012 at 3:46 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: This is the response I posted to the bugzilla issue: I would like to see a better motivation present for why this change is important. In particular, it is a deviation from the ECMAScript standard. While syntactic extensions to the Date.parse syntax is allowed by the specification. It is not particularly a good idea. In particular, every time a specific implementation adds such a non-standard extension, it creates a potential cross-browser interoperability hazard. Apparently these extensions are not motivated by a desire to improve interoperability as reference [1] shows that none of Firefox, IE, and Safari currently provide these extensions. Chrome apparently does (and also Opera??). That format has been recognized by Opera's Date parsers for at least 5-6 years. I don't think you'll find there being a reason for that other than a parser that tries to be permissive about formats allowed, and lets that through (which few others have.) --sigbjorn / s...@opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
