Re: callable objects ?
Le 19/04/2012 01:00, Brendan Eich a écrit :
David Bruant wrote:
var p = Proxy(target, {});
p(); // throws exception because the proxy is reported as not
having
// a @call property
In the get trap of the proxy, the @call private name is transformed into
its public conterpart. When, by default, the trap forwards to the
target, the public alter-ego is coerced into a string. Consequently, the
actual @call property of the target isn't found.
Hmm, I see. The idea was to avoid leaking private names via hostile
proxies, but here we have a friendly proxy that wants to get the
private-named target property.
Yes. The interaction of proxies and private name has only been
considered under the consideration that proxies can be hostile. And
indeed, there are cases where there is no need to protect the private
name from the proxy. One is publicly available private names (aka
unique names).
That was the root of the reasoning behind Alternative proposal to
privateName.public [1].
I've summurized some approaches [2] that could be taken.
With direct proxies, if the target already has the private-named
property, and the handler ({} here) has no traps that might steal a
non-substituted private name, why would we substitute the public name
for the private @call?
This doesn't scale. Private names could be added or removed from the
target by some who have direct access to it (not intermediated with a
proxy).
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-December/018908.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2011-December/019005.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Le 19/04/2012 01:54, Brandon Benvie a écrit : (or you simply don't trap the access, which is the route for [[prototype]], [[instanceof]], etc which now makes even more sense to me in light of this) Not trapping seems like a valid option [1]. The rationale for the .public counterpart in the private name proposal is that the proxy should not have access to the private name. However, if it doesn't (directly or indirectly), it can't do anything useful. Under these conditions, the trap might as well not been called. David [1] https://mail.mozilla.org/pipermail/es-discuss/2011-December/019005.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
On 19 April 2012 00:45, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 18, 2012, at 2:48 PM, Brendan Eich wrote: David Herman wrote: *Please*, let's do this right. This says to me (what I originally expected) that duplicate property name at any ply in an object pattern should be an early error. Anyone disagree? I wholeheartedly agree. I'm not sure that the concern about repeated side-effects is very significant given that any property access can have arbitrary side-effects including adding and removing properties from the RHS object. I agree with that, too, though my impression is that implementations already get the exact sequences of such observable steps wrong in quite a few other cases (I played around with corner cases when doing proxies). The case above looks easy enough, but in general, the fewer possible micro observations the better. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
@David: I am all ears to your comments! @Erik: As you may have read in this thread, it seems that the major request is for the removal of comments. So, here I announce it: the feature has just bumped to the top of the TODO list :) Thanks for the pointers. I'll probably have a closer look at the functional coverage of Traceur, as it has clearly evolved since I last watched it. On Wed, Apr 18, 2012 at 11:06 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: This is quite interesting. I really feel that the comment syntax is pretty ugly. Parsing JS is non trivial but it is not a performance issue. If you expect this to have some uptake I would expect it to use the real module syntax and not rely on comments. By coincidence I landed import support to Traceur last night. You might want want to check it out. It also doesn't use the latest syntax since the current BNF on the wiki is incomplete. http://code.google.com/p/traceur-compiler/source/browse/#git%2Ftest%2Ffeature%2FModules http://code.google.com/p/traceur-compiler/source/detail?r=f4f8788860f624ca1b02883890325cbb4ee9c1eb Traceur does have a CodeLoader that allows loading external js files but it is not very convenient to use at this point. We have an open bug to allow offline compilation of modules with external dependancies. http://code.google.com/p/traceur-compiler/issues/detail?id=87 -- erik -- -- Xavier CAMBAR @xcambar https://twitter.com/#!/xcambar T: +33 6.84.29.46.83 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const, attempt 2 (Re: Legacy const)
On 18 April 2012 19:13, Geoffrey Sneddon gsned...@opera.com wrote: I've just had it pointed out to me that my original email made little sense, so let's try again: const has historically been needed in non-strict/strict code for web compatibility on non-IE code (typically either down to server-side UA sniffing or just explicitly non-support of IE). IE still doesn't support it, which may suggest it's not needed for compatibility any more, but as far as I can tell removing it would break enough to make it infeasible. As such, we should spec it: likely block-scoped in modules, and function-scoped otherwise. We should only really not spec it if we can get everyone who currently supports it to drop it. IE has consts, use execScript with vbs. I think Andrea did a blog post on it: http://webreflection.blogspot.co.uk/2007/10/cow-javascript-define-php-like-function.html The const keyword is a little freaky overall, Firefox seems to support it yet Opera (last time I checked) supports the keyword but doesn't perform a const operation. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
On Wed, Apr 18, 2012 at 10:21 AM, Xavier CAMBAR xcam...@gmail.com wrote:
Thanks for your comments, I'm glad you liked it.
About CommonJS, the compatibility is the other way round. Shepherd can
load commonJS modules without the addition of the in-comment syntax
declaration. In such a case, require is wrapped to load whether an already
loaded ES6 module or use commonJS's require. furthermore, exports or
module.exports is used as the public API of the ES6 module (which is
basically the definition :) ). This is really useful for 3rd party modules.
Removing the comments would be possible, but it would require a much
heavier parsing phase, and would probably require a full-blown JS parser,
such as Esprima. it would be probably computationnally too heavy for the
browser (read: for the user) without a systematic and automatic
code-rewrite to ES5, optionnaly accompagned with some minification.
Yes, that's what I was getting at in my response. I know it would be a much
bigger effort, which is why I understand the approach. If I were to do the
project, though, I would assume that if it were done in the browser, that
would be purely for development - it should all be precompiled for
production. You could even use the module imports to do script
concatenation.
On the other hand, the great advantage of using comments is that they act
as placeholders for the syntax declaration, and are very easy to locate
with a single regular expression.
This is beneficial for the implementation, but not the user.
More realistically, I plan on allowing multiple module declarations in a
single file (currently one only), where module implementations would be
syntactically separated by the numerous definitions (ie, the implementation
of a module ends at the beginning of the next module declaration).
But yes, I am looking for an efficient way to remove the comments, which
would be the only way Shepherd could be used as an efficient
Harmony:modules polyfill. Maybe I'll have to play around with more
minimalist placeholders, such as:
Personally, I think you'll want the full polyfill as a target. You can get
there incrementally by removing comments, but until it matches the full
spec, I don't think you'll see widespread adoption. IMHO anyway.
//s6d
module myModule {
import x from X;
export a, b, c, d;
}
//-s6d
...though the ending comment doesn't seem necessary.
And please don't blame me for the possible terrible idea, I'm thinking
aloud on this one! ;)
I think I would actually prefer comments over this. I wrote some code long
before module proposals that basically made my JavaScript files work like
Java files (Java is the other language we use), basically import
statements, exports were just based on the filename matching the class or
object definition inside. I would probably change it to be more like
modules if I did it now, maybe even how you did it. Anyway, point is, I put
the imports in the comments just like you for two reasons.
1. easier to find with regexes, didn't have to parse full js
2. didn't break existing JavaScript tooling i.e. syntax highlighting
Its the second reason that I would prefer your current comment based
solution over the new one you propose. Unless you support writing modules
the way I expect them to be written, I would rather have them in comments.
The tradeoff to be found is the following: As of today, no browser has a
stable release that allows harmony modules (yeah, the latest V8 has an
option, well...). Whatsmore, the syntax is just a proposal which is updated
almost every quarter. So do we want to allow files that work on today's
engines and can be enhanced with Harmony:modules' features thankd to
Shepherd, or do we want Harmony compliant files that won't run natively on
any stable engine we can find today?
I chose the first path, but the discussion remains open. I'll be happy to
hear your thoughts on that point.
Support is coming. I look at it this way. Some day relatively soon, ES6
modules will be in node. Soon after that they will start showing up in
browsers. Over the course of the next year, I bet you'll see module support
in at least firefox and chrome. If you set your sights on full modules now,
you'll have code that doesn't need to be rewritten a year from now. A
polyfill will happen, do you want to write it?
- Russ
Xavier
On Wed, Apr 18, 2012 at 3:11 PM, Russell Leggett
russell.legg...@gmail.com wrote:
This is great! I've been considering doing the same thing, but I haven't
found the time. When you say it is compatible with CommonJS modules, does
that mean that you can do an import using ES6 syntax and have the result do
a CommonJS require?
The big thing I'm noticing is that all of the examples are inside of
comments, and your module definitions including exports are all separate
from the actual code for those exports. I'm assuming that means somebody
couldn't actually take the ES6 module examples and
Re: callable objects ?
I still like the idea of distinguishing private from unique names, where private = invisible via reflection proxies and unique = visible via reflection proxies (cf. the thread David linked to). As for how direct proxies might help: yes, I've previously proposed several solutions: - One was to not allow proxies to trap private names, and always forward private name access unconditionally, as mentioned by Brandon. - The other was essentially Brendan's current proposal: if the trap is missing, forward the private name access to the target without converting it into a public object, except I also proposed factoring out private name access into separate getPrivate/setPrivate traps. See: https://mail.mozilla.org/pipermail/es-discuss/2011-December/018937.html https://mail.mozilla.org/pipermail/es-discuss/2011-December/018938.html Cheers, Tom 2012/4/19 David Bruant bruan...@gmail.com Le 19/04/2012 01:54, Brandon Benvie a écrit : (or you simply don't trap the access, which is the route for [[prototype]], [[instanceof]], etc which now makes even more sense to me in light of this) Not trapping seems like a valid option [1]. The rationale for the .public counterpart in the private name proposal is that the proxy should not have access to the private name. However, if it doesn't (directly or indirectly), it can't do anything useful. Under these conditions, the trap might as well not been called. David [1] https://mail.mozilla.org/**pipermail/es-discuss/2011-** December/019005.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2011-December/019005.html __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Le 19/04/2012 16:55, Tom Van Cutsem a écrit : I still like the idea of distinguishing private from unique names, where private = invisible via reflection proxies and unique = visible via reflection proxies (cf. the thread David linked to). Additionally to this proposal, if the getOwnPropertyNames non-configurability invariant (must report all sealed properties) can be renegociated to not necessarily include unique names, then proxies can use unique names as private names (and not be forced to disclose them on Object.getOwnPropertyNames()). By the way, I'm realizing now that the getOwnPropertyNames trap does string coercion on elements of the array returned by the trap. How will this work with private names? Hopefully, these won't be coerced, but based on what? Will private names have a particular [[Native Brand]]? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
You've made solid points here!
The various comments I've received from here and there show the same
direction: someday, modules will be available, and Shepherd will then be
unnecessary for supported engines. Polyfilling remains. If it ever gains
some momentum, it is highly related to how it follows the specifications
and remains usable in supported engines.
It appears then that removing comments is a must-have. Keeping
backward-compatibility maybe was a bad idea from the very beginning after
all. If you look at the example of the home page (
xcambar.github.com/shepherd-js), who will seriously consider developing a
module with the relevant code architecture in mind, and then proclaim Hey,
you can also use it as a good old module-less JS file, but it will put crap
all over you global scope by exposing its inner parts ? I hope no one will.
As a conclusion, Shepherd seems to be going its way to a compliant polyfill
for Harmony modules. I should change the script type to text=harmony to
reflect this :p
But you shouldn't expect the tools you use not to break. Unless they parse
the modules syntax, of course! This is why I hardly understand your point
on the *proposed* new syntax. It's much more lightweight, is parsed easily
(*I* am the only one happy, but that matters at some point ;) ) and works
natively on module-enabled engines.
It may IMO constitute a valid first step, as it reduces the effort for the
user drastically.
Xavier
On Thu, Apr 19, 2012 at 3:11 PM, Russell Leggett
russell.legg...@gmail.comwrote:
On Wed, Apr 18, 2012 at 10:21 AM, Xavier CAMBAR xcam...@gmail.com wrote:
Thanks for your comments, I'm glad you liked it.
About CommonJS, the compatibility is the other way round. Shepherd can
load commonJS modules without the addition of the in-comment syntax
declaration. In such a case, require is wrapped to load whether an already
loaded ES6 module or use commonJS's require. furthermore, exports or
module.exports is used as the public API of the ES6 module (which is
basically the definition :) ). This is really useful for 3rd party modules.
Removing the comments would be possible, but it would require a much
heavier parsing phase, and would probably require a full-blown JS parser,
such as Esprima. it would be probably computationnally too heavy for the
browser (read: for the user) without a systematic and automatic
code-rewrite to ES5, optionnaly accompagned with some minification.
Yes, that's what I was getting at in my response. I know it would be a
much bigger effort, which is why I understand the approach. If I were to do
the project, though, I would assume that if it were done in the browser,
that would be purely for development - it should all be precompiled for
production. You could even use the module imports to do script
concatenation.
On the other hand, the great advantage of using comments is that they act
as placeholders for the syntax declaration, and are very easy to locate
with a single regular expression.
This is beneficial for the implementation, but not the user.
More realistically, I plan on allowing multiple module declarations in a
single file (currently one only), where module implementations would be
syntactically separated by the numerous definitions (ie, the implementation
of a module ends at the beginning of the next module declaration).
But yes, I am looking for an efficient way to remove the comments, which
would be the only way Shepherd could be used as an efficient
Harmony:modules polyfill. Maybe I'll have to play around with more
minimalist placeholders, such as:
Personally, I think you'll want the full polyfill as a target. You can get
there incrementally by removing comments, but until it matches the full
spec, I don't think you'll see widespread adoption. IMHO anyway.
//s6d
module myModule {
import x from X;
export a, b, c, d;
}
//-s6d
...though the ending comment doesn't seem necessary.
And please don't blame me for the possible terrible idea, I'm thinking
aloud on this one! ;)
I think I would actually prefer comments over this. I wrote some code long
before module proposals that basically made my JavaScript files work like
Java files (Java is the other language we use), basically import
statements, exports were just based on the filename matching the class or
object definition inside. I would probably change it to be more like
modules if I did it now, maybe even how you did it. Anyway, point is, I put
the imports in the comments just like you for two reasons.
1. easier to find with regexes, didn't have to parse full js
2. didn't break existing JavaScript tooling i.e. syntax highlighting
Its the second reason that I would prefer your current comment based
solution over the new one you propose. Unless you support writing modules
the way I expect them to be written, I would rather have them in comments.
The tradeoff to be found is the following: As of today, no browser
Re: callable objects ?
David Bruant wrote: By the way, I'm realizing now that the getOwnPropertyNames trap does string coercion on elements of the array returned by the trap. How will this work with private names? Hopefully, these won't be coerced, but based on what? Will private names have a particular [[Native Brand]]? My understanding (not necessarily reflected in the private name objects proposal, alas) was that we would not break *any* existing reflection facility (for-in, Object.getOwnPropertyNames, etc.) by suddenly returning non-string property names. No reflection on private names. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const, attempt 2 (Re: Legacy const)
gaz Heyes wrote: IE has consts, use execScript with vbs. I think Andrea did a blog post on it: http://webreflection.blogspot.co.uk/2007/10/cow-javascript-define-php-like-function.html Any port in a storm, but c'mon -- we're talking about 'const x = 42;' written in JS. That has never been supported in IE and I recall an IE blog post (from Allen, if memory serves) about why not. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const, attempt 2 (Re: Legacy const)
On Apr 19, 2012, at 10:58 AM, Brendan Eich wrote: gaz Heyes wrote: IE has consts, use execScript with vbs. I think Andrea did a blog post on it: http://webreflection.blogspot.co.uk/2007/10/cow-javascript-define-php-like-function.html Any port in a storm, but c'mon -- we're talking about 'const x = 42;' written in JS. That has never been supported in IE and I recall an IE blog post (from Allen, if memory serves) about why not. http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx But that was then and the world is different today. I certainly don't know anything about the plans for IE10. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
On Thu, Apr 19, 2012 at 9:11 AM, Russell Leggett
russell.legg...@gmail.comwrote:
[snip]
Support is coming. I look at it this way. Some day relatively soon, ES6
modules will be in node. Soon after that they will start showing up in
browsers. Over the course of the next year, I bet you'll see module support
in at least firefox and chrome.
In Chrome Canary, with Harmony flag enabled...
module Foo {}
(Foo in this); // true
:)
But, Foo is still undefined.
Rick
If you set your sights on full modules now, you'll have code that doesn't
need to be rewritten a year from now. A polyfill will happen, do you want
to write it?
- Russ
[snip]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
On Apr 18, 2012, at 2:48 PM, Brendan Eich wrote:
David Herman wrote:
*Please*, let's do this right.
This says to me (what I originally expected) that duplicate property name at
any ply in an object pattern should be an early error.
Anyone disagree?
I got as far as being ready to type into the spec. the first line to implement
this restriction. Then my reservations flamed-up.
If you think of a destructuring declaration as simply a way to provide the
initial values to a set of declaration is isn't so clear that duplicate
property names are bogus. Consider:
//initialize some variable with default objects
let {
unidentifedAdult: mom,
unidetifiedAdult: dad,
unidentiedChild: brother,
unidentifiedChild: sister
} = peopleConstants;
why is this less desirable than:
//initialize some variable with default objects
let mon = peopleConstants.unidentifiedAdult,
dad = peopleConstants.unidentifiedAdult,
brother = peopleConstants.unidentifiedChild,
sister = peopleConstants.unidentifiedChild;
The former style is less familiar, but is it really bad enough to disallow at
the language level?
Disallowing duplicate property names may make sense if you think about
destructuring in ES declarations as pattern matching (which it really isn't)
or a means to break a composite into its constituent parts. But duplicate
properties as initializers for a set of variables seem quite reasonable.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
Russell,
I've worked on this branch during the evening:
https://github.com/xcambar/shepherd-js/tree/20120420_CommentRemoval,
Currently, single line comments must still wrap the module declaration, but
this version offers a good comparison point in regards to the master branch.
Rick,
I've seen this, it is encouraging that Google considers adding support. But
there's a long way to go before a stable release.
By the way, the V8 engine what will come in Node 0.8 has Harmony flags, and
one of them is about modules.
Xavier
On Thu, Apr 19, 2012 at 9:46 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Apr 19, 2012 at 9:11 AM, Russell Leggett
russell.legg...@gmail.com wrote:
[snip]
Support is coming. I look at it this way. Some day relatively soon, ES6
modules will be in node. Soon after that they will start showing up in
browsers. Over the course of the next year, I bet you'll see module support
in at least firefox and chrome.
In Chrome Canary, with Harmony flag enabled...
module Foo {}
(Foo in this); // true
:)
But, Foo is still undefined.
Rick
If you set your sights on full modules now, you'll have code that
doesn't need to be rewritten a year from now. A polyfill will happen, do
you want to write it?
- Russ
[snip]
--
--
Xavier CAMBAR
@xcambar https://twitter.com/#!/xcambar
T: +33 6.84.29.46.83
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
On Apr 19, 2012, at 2:18 PM, Allen Wirfs-Brock wrote:
//initialize some variable with default objects
let {
unidentifedAdult: mom,
unidetifiedAdult: dad,
unidentiedChild: brother,
unidentifiedChild: sister
} = peopleConstants;
why is this less desirable than:
//initialize some variable with default objects
let mon = peopleConstants.unidentifiedAdult,
dad = peopleConstants.unidentifiedAdult,
brother = peopleConstants.unidentifiedChild,
sister = peopleConstants.unidentifiedChild;
Well, it's rare that you *need* to re-evaluate the dot-pattern. It saves
typing, repetition (DRY!), side-effects, and running time to evaluate each
selector only once:
let mom = peopleConstants.unidentifiedAdult,
dad = mom,
brother = peopleConstants.unidentifiedChild,
sister = brother;
And you should be able to do that just fine with nested as-patterns:
let { unidentifiedAdult: mom as dad, unidentifiedChild: sister as brother }
or
let { undentifiedAdult as mom as dad, unidentifiedChild as sister as
brother }
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
