Re: what kind of problem is this fat arrow feature trying to solve ?
Le 02/10/2013 10:37, Claude Pache a écrit : +1. The big win of arrow-functions, is that it prevents from using various ad-hoc kludges (`var that = this`, `[].some(..., this)`, etc), whose sole goal is to defeat some unwanted feature (proper `this` binding in callbacks). Not a killing-feature, but a nice addition that will help to reduce noise in code. And for those that do not use any longer var that=this but .bind(this) the transition is easy: just remove .bind(this) and replace function by fat arrow, one of the most wanted feature for me. -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: what kind of problem is this fat arrow feature trying to solve ?
Andrea, it's difficult to understand why you think the fat arrow does
not help or I misunderstood your point, if |this| is already bound to
something, like for events, then you don't need it, if you want to bind
to something else then you use bind, if you want to bind to the outer
|this| then you use the fat arrow, that's extremely usefull, even in a
DOM env, because for example while handling events you probably have the
case of binding |this| again inside, but DOM is not only events, I am
using a lot bind(this) in DOM, node, etc and will replace it as
previously mentioned by the fat arrow when available.
Regards,
Aymeric
Le 02/10/2013 20:11, Andrea Giammarchi a écrit :
You need to be sure about the `this` because today you can
`bind(anyObject || this)` while with fat arrow you can only bind
`this` so you need to be sure that the function context, the one
everybody has always borrowed through call and apply, is the one you
expect to be.
In a new direction where instanceof is being discouraged, the usage of
this become critical.
As shortcut, fat arrow fails. `var o = {method: () = whatver;};`
As DOM listener it brings what `handleEvent` does since ever.
```javascript
var o = {
init: function () {
document.addEventListener('click', this);
// virtually the same of
document.addEventListener('click', (e) = this.handleEvent(e));
},
handleEvent: function () {
this === o;
}
};
```
So I don't see many advantages on DOM world.
Once again, I am trying to understand where is the glory of this new
feature.
I am not saying it should not be there, ES6 classes and generators
already breaks the old syntax so it won't hurt a new utility as fat
arrow is but where this will be exactly a better approach to the
current situation ?
The only one that comes into my mind is the `once` event listener in
node or eddy.js ... but `once` a part, and I admit in there it's
handy, I cannot see many other real/concrete usages.
In CoffeeScript the fat arrow behaves differently having a dynamic
this, am I correct?
So whoever is comparing fat arrow with CoffeeScript should be aware
these are completely different beasts and there was my question about
what is solving for the real world.
No need to talk about use strict.
Thanks
On Wed, Oct 2, 2013 at 11:01 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
fat arrow does not add any capabilities but create the need to
be sure about the context.
This does not make sense. The problem of being unsure about which
this already exists. Adding arrows does not make it worse. The
new syntax makes it better, compared to 'var self = this;' or
.bind(this) hacks that are more verbose and easy to forget -- that
is, whose absence is easy to overlook.
In use strict fat arrow will bring a lovely `undefined` wich
is undesired so nothing is solved in there.
Stop comparing apples to oranges. If we have today
use strict;
function foo() {
...
setCallback(function () { ... this ...}.bind(this));
}
Then you have no greater or lesser incidence of undefined-this
bugs due to someone calling foo() instead of foo.call, foo.apply,
or obj = {method:foo}, obj.method() by changing this code to use
an arrow:
use strict;
function foo() {
...
setCallback(() = {... this ...});
}
If you don't like strict mode, keep that out of this thread.
Incidence of undefined-this bugs due to it do not change with arrows.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES Native Mode proposal
There are other cases, like malicious code injection. I don't know if it's really feasible without redefining the DOM on top of it but I feel the need since a long time, something that makes sure you are using the right XMLHttpRequest or other and not a modified one. And something that prevents a bad script to do something like setTimeout(change_globals,xxx) Regards, Aymeric Le 26/09/2013 01:16, Andrea Giammarchi a écrit : I think is not ... or at least is not real-world possibility. We have two scenarios: 1. you know what you include 2. you are the library included In first case you don't need anything because you know the code and you know no script will hurt so you can even do whatever you want with natives ... who cares if that's convenient for you, why not. The second case you might arrive too early, so no other library could work in a frozen env, or too late, the env has been already modified you can freeze it and live in troubles for you and other scripts. I am usually the guy living in the first case .. with as less external dependencies as possible and where code is OK even if extended in a reasonable way but I don't think there is a reasonable solution for the second case. Once again we all trid in the past and failed for usability, performance, not so secured env ... etc etc ... As summary if you have a party in your house ... you better know your guests :D On Wed, Sep 25, 2013 at 3:48 PM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: It's not easy to freeze the world like Caja is doing, and it's not easy to have a library that takes care of it securely, and the use case is not always to use modules to have a fresh global. Some years ago, doing widgets stuff inside web pages, I had a RestoreNativeVar function restoring natives using strange hooks like taking them from iframes (no comments...) The issue is probably not TC39 only, but looking at W3C security groups specs which apparently have some hard time defining something secure, maybe SES concepts are coming late in the TC39 schedule, all new Web API define more globals, this is usefull to have something that freezes the entire global when you need it instead of hacking around. Regards, Aymeric Le 25/09/2013 23:50, David Bruant a écrit : Le 25/09/2013 17:41, Michaël Rouges a écrit : Hi all, Given the number of scripts from various sources that may be contained in a web page, there may be prototypingconflicts. Be careful about what you include? To be proactive in that process, freeze all builtins beforehand. You'll know soon enough if something breaks. If you do want to enhance prototype, isolate this code and run it before freezing builtins. The module loader API has something close to what you ask: http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#loader.prototype.definebuiltins_obj David ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Native Mode proposal
I have just commented the Safe, closure-free... thread, and gave some thoughts about CSP, as mentioned I have some hard time understanding what it does protect, there is no mechanism for setting independently script authorities, see the example I provided and the responses I got. For those interested I provided in the CSP thread a link to a FF bug report where it's explained how some security policy (here Websocket spec) forces me to do insecure things. I don't know what list can take care of it, there is a discussion in [1] too, for now I did not see really solid arguments showing that I could be wrong. Maybe a solution could be combination of CSP and SES, I think SES should come now, as far as I remember it is planned for ES8, seems too late. Solving the code loading issue is indeed the key point, but is it feasible? Regards, Aymeric [1] https://groups.google.com/forum/#!topic/mozilla.dev.security/6qBHmVAhtYY Le 26/09/2013 10:22, David Bruant a écrit : Le 26/09/2013 09:10, Aymeric Vitte a écrit : There are other cases, like malicious code injection. CSP goes a long long way in preventing these. I don't know if it's really feasible without redefining the DOM on top of it but I feel the need since a long time, something that makes sure you are using the right XMLHttpRequest or other and not a modified one. In environments where you don't have the option of freezing all built-ins, running your code first allows you to keep a reference to the initial XMLHttpRequest. You may then wonder: how can I enforce running first? = If you're in control of the webpage, it really is up to you to run trusted code *before* any other scripts. If you're building a library other will include at any point in time they want, hope for a standard environment, expect nothing. And something that prevents a bad script to do something like setTimeout(change_globals,xxx) The problem here is exactly the same problem than viruses. The only reason viruses exist at all is the design mistake that led operating systems to consider than programs you (human being) start, run with the same authority than you. Indeed, any program you run can throw away all your files, send them over the network to whatever server, etc. Hence viruses. Seriously, how did we end up in a world where Windows Vista (and later? I've stopped Windows) think it's a good idea to ask for a confirmation pretty much after any click where could would be run? If Windows has a way to know the second click is secure, how much harder is it to make sure the *first* click is secure!! This is insane! Related is this interesting talk: The SkyNet Virus - Why it is Unstoppable; How to Stop it http://www.erights.org/talks/skynet/ It's old and low-quality (video, not content), but it's really good. In my opinion, the good question isn't how to prevent a bad script to do something like ...?, but rather how can I make sure that scripts, any script, can be loaded only with the authority it needs?. How did the bad script you're talking about above ended up with the authority to change globals? CSP is a good start and says don't run scripts that aren't whitelisted. You prevent scripts you haven't chosen to run at all. For sure, they won't change globals. Caja and Module loader allow to run partially trusted code with fine-grain (object-level) control of the exact amount of authority you want. In any case, the problem starts (and likely ends) with how code is loaded. When this problem is solved (and I think it pretty much is with CSP and Caja/Module Loader), then most script-related security problems are solveable. David -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Native Mode proposal
Le 26/09/2013 11:43, David Bruant a écrit : Le jeu. 26 sept. 2013 11:11:40 CEST, Aymeric Vitte a écrit : For those interested I provided in the CSP thread a link to a FF bug report where it's explained how some security policy (here Websocket spec) forces me to do insecure things. I don't know what list can take care of it, there is a discussion in [1] too, for now I did not see really solid arguments showing that I could be wrong. I answered on the webappsec thread. Firefox blocks mixed content for good reasons. When receiving an HTTPS page, the browser shows lots of signs of the page being secure. If the page starts loading code/style/content with HTTP, these are subject to man in the middle attacks and suddenly, the browser gives a false sense of security to the user. Mixed content is not blocked today. Again, it's difficult to say which one is more insecure between http with https or https with http, the first one is subject to a mitm attack since the begining. Firefox isn't forcing you to do insecure things. Firefox is forcing you to make a choice: go all the way secure (so that it can shows strong signal to the user) or use HTTP. I am not saying FF is the problem, FF follows the Websocket spec, which does not allow ws with https. I am explaining why I can not use wss (routers can not have trusted certificates), so I am forced to fallback to http. It's easy to deny the issue but that's a real life use case. Maybe a solution could be combination of CSP and SES, I think SES should come now, as far as I remember it is planned for ES8, seems too late. SES exists now... sort of... with Caja. You don't need to wait, it's already available. Module loaders are also a major step forward. Not very intuitive to use as far as I remember. Solving the code loading issue is indeed the key point, but is it feasible? Can you describe ways in which it isn't? Do you know a way (even theoretical) to safely load code with web mechanisms that can defeat a mitm? This would necessarly imply another check mechanism on top of SSL/TLS David -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Safe, Closure-free, Serializable functions
I would like to defend against a potential mitm/code injection and
ideally against globals modifications.
Unfortunately I have the ws problem which screw up a little bit the use
case. So, we have the scenario that you see at the begining of [1],
forget about the unsafe-inline, I thought it could apply to the worker
but it does not.
I tried (as an experiment) to apply this case using CSP and I don't
understand very well what the result does secure, as well as [2]
Regards
Aymeric
Le 26/09/2013 18:14, Alex Russell a écrit :
It's unclear what your threat model is. What do you want to defend,
from who or what, and for how long?
On 26 Sep 2013 00:40, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
This is similar to the Native thread as Andrea mentioned.
Then when SES is coming?
It seems urgent to boost it, I have tried CSP recently, or at
least what works today, see [1] and [2], unfortunately I don't see
quite well what it does secure, today and tomorrow.
Regards,
Aymeric
[1]
http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0058.html
[2]
http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0067.html
Le 26/09/2013 02:32, Mark S. Miller a écrit :
Hi François, your goals here have a tremendous overlap with SES.
In what ways is SES not satisfactory for these purposes?
The best short-but-accurate summary of SES, sufficient for this
question, is http://research.google.com/pubs/pub40673.html
section 2.3.
SES does not remove eval and Function, but rather replaces them
with confining equivalents which should be better for your
purposes. You can get SES from either
``https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/
or https://code.google.com/p/es-lab/source/browse/trunk/src/ses/.
The security of SES is analysed at
http://theory.stanford.edu/~ataly/Papers/sp11.pdf
http://theory.stanford.edu/%7Eataly/Papers/sp11.pdf.
On Wed, Sep 25, 2013 at 4:29 PM, François REMY
francois.remy@outlook.com
mailto:francois.remy@outlook.com wrote:
Hi,
TLDR == The web needs a way to express executable code that
does not rely on its parent context, is guaranteed to be
side-effect-free, and can be executed safely anywhere (even
in a different thread/worker/window/device, or as callback
for browser code being executed while the DOM is not ready to
be accessed)
It's been some time I've been working on this idea of a
Closure-free, Serializable function. This kind of function
would have no access to the parent closures they are defined
in, and only limited (read-only) access to the enclosing
environment (read-only Math, Object, Array, others...).
To the difference of other functions, those objects would not
be affected by the JavaScript running elsewhere on the page,
so in this closure-free function, Array.prototype.slice is
guaranteed to be the native slice function, not some kind of
polyfill or replaced function.
|function sort(array) as serializable {
|Array.prototype.sort.call(array);
|}
|function sqrt(number) as serializable {
|return Math.sqrt(number);
|}
|function __BAD_CODE__() as serializable {
|return new XMLHttpRequest(); // xhr not defined in ES6
|}
Trying to export a global variable or modify any of the host
environment-defined objects would fail.
|function __BAD_CODE__(number) as serializable {
|globalNumber = number; // cannot write into the
global object
|}
|function __BAD_CODE__() as serializable {
|Object.prototype.doSomething=function() {}; //
cannot write into the native objects
|}
It's also important to note that any Object or Array created
inside this context will be passed to the calling context by
deep-cloning (or by replacing the safe Math object by the
host Math object of the calling code in the case of
environmental objects). Objects that can't be cloned
(non-serializable functions, for example) are just
transformed into null. We could also maybe use the idea of a
proxy though deep-cloning seems safer.
This makes sure it's impossible to leak the safe objects to
the calling context in any way (ie: the calling code can leak
anything to the called code, but not the reverse).
|var RealSin = Math.sin;
|Math.sin=function() {};
|
|function giveMeMath() as serializable {
|return [Math, Math.sin];
|}
|
|var [m,s] = giveMeMath();
|// s
Re: Safe, Closure-free, Serializable functions
Le 26/09/2013 20:14, Alex Russell a écrit : On Thu, Sep 26, 2013 at 9:56 AM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: I would like to defend against a potential mitm/code injection and ideally against globals modifications. Only one of those is a threat (MITM). The other is an effect of something happening (which you may or may not want). Conflating them isn't meaningful. I am not conflating them, the idea is to defend against everything, as far as possible, including physical attacks like your colleague hacking inside your browser while you have left your office during some time, I don't find it so unlikely to happen, and quasi impossible to detect. Regards, Aymeric -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Native Mode proposal
It's not easy to freeze the world like Caja is doing, and it's not easy to have a library that takes care of it securely, and the use case is not always to use modules to have a fresh global. Some years ago, doing widgets stuff inside web pages, I had a RestoreNativeVar function restoring natives using strange hooks like taking them from iframes (no comments...) The issue is probably not TC39 only, but looking at W3C security groups specs which apparently have some hard time defining something secure, maybe SES concepts are coming late in the TC39 schedule, all new Web API define more globals, this is usefull to have something that freezes the entire global when you need it instead of hacking around. Regards, Aymeric Le 25/09/2013 23:50, David Bruant a écrit : Le 25/09/2013 17:41, Michaël Rouges a écrit : Hi all, Given the number of scripts from various sources that may be contained in a web page, there may be prototypingconflicts. Be careful about what you include? To be proactive in that process, freeze all builtins beforehand. You'll know soon enough if something breaks. If you do want to enhance prototype, isolate this code and run it before freezing builtins. The module loader API has something close to what you ask: http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#loader.prototype.definebuiltins_obj David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises: final steps
I have not read everything about the promise/future/re-promise subject but what I have read seems to show that everyone has a personal understanding of the thing. So please see http://lists.w3.org/Archives/Public/public-webcrypto/2013Sep/0003.html , code example that I have written for WebCrypto (ie real working case not using WebCrypto rewritten with WebCrypto promises), as explained I am using 'done' despite of the fact that it might be removed, because I don't see why I should use 'then' if I am not chaining anything. As explained again, the example shows maybe that promises here are a kind of artifice, until other APIs implement promises. How should I write this without 'done'? Regards Aymeric Le 08/09/2013 19:06, Anne van Kesteren a écrit : (Added back the other lists.) On Fri, Sep 6, 2013 at 3:58 AM, Brendan Eich bren...@secure.meer.net wrote: Let's put done back in. It's the right thing. Given what has been said thus far https://github.com/domenic/promises-unwrapping/issues/19 my inclination is still to leave it out initially and give a version without done() six months to a year to mature. Not having done() can make promises harder to debug in the short term, but adding done() is trivial to do later. And given the lack of native promise implementations to date there's no way for us to test the done()-less design without trying it first. -- jCore Email : avi...@jcore.fr Peersm : http://www.peersm.com iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deterministic enumeration
I don't know what is a determinist way for enumeration and who is right (I would be more enclined to keep the chronological order of property settings but if the strawman says the contrary there must be a good reason), but not knowing about #164, I wrote one day : https://code.google.com/p/v8/issues/detail?id=2353 This was closed about 2s after I wrote it, but here what is not determinist at all is that the enumeration order can change depending on what you are doing. Regards, Le 25/04/2013 20:56, Brendan Eich a écrit : David Bruant wrote: Hi, I've seen a bug report on Firefox [1] and was wondering whether deterministic property enumeration [2] was still on the table for ES6. My comment from that bug: https://bugzilla.mozilla.org/show_bug.cgi?id=865760#c5 Ignoring the SpiderMonkey threshold, we do have http://wiki.ecmascript.org/doku.php?id=strawman:enumeration. It was not promoted to harmony:proposals status for ES6. It's a bit late to jam in, but implementations along with that strawman should try to converge. I doubt the threshold will find consensus. There's a long V8 issue on enumeration not using insertion order: http://code.google.com/p/v8/issues/detail?id=164 I believe. Closed: WorkingAsIntended, still drawing fire from developers. /be Thanks, David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=865760 [2] http://wiki.ecmascript.org/doku.php?id=strawman:enumeration ___ 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 -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
So, my suspicion was correct, I am using DataView methods like this (https://github.com/Ayms/abstract-tls/blob/master/lib/abstract-tls.js#l280-332 here and on other projects) for historical reasons, because I started from node.js's buffers methods and then switched to ArrayBuffers with node.js's like methods, because in some cases I needed to use both at the same time or to be able to switch easily from one to another. Then the use is not correct in theory, now performances seem to be OK (except node.js), so maybe most of the implementations are instantiating once a DataView for a given ArrayBuffer and keeping reference to it when you call it again? Regards, Le 03/04/2013 00:52, Kenneth Russell a écrit : Yes: API consistency. An ArrayBuffer is opaque; to work with the data it contains, instantiate a view. On Tue, Apr 2, 2013 at 3:36 PM, Kevin Gadd kevin.g...@gmail.com wrote: Is there a reason why DataView wasn't specified as static methods that take an ArrayBuffer in the first place? That would solve the problem of figuring out when/how often to create DataView instances, and eliminate the garbage created by using DataViews. On Tue, Apr 2, 2013 at 3:23 PM, Kenneth Russell k...@google.com wrote: On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Le 02/04/2013 04:24, Kenneth Russell a écrit : Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. When you are streaming things, what's the correct use of DataViews? ie : you are supposed to create each time you want to read some bytes a DataView (which can be optimized or whatever, but still with some costs)? Maybe it's outside of the scope of this discussion, I have already provided examples, I still suspect that I am using it wrongly or that ArrayBuffers are more adapted to webgl (ie static buffer manipulation) than network streaming (ie dynamic buffer manipulation). Probably I am wrong but really would like to know then what's the correct use. If I understand your question, then the correct use of DataView is: upon receiving an ArrayBuffer, create a DataView referring to it. When iterating down the contents of the ArrayBuffer, continue to use the same DataView instance, just incrementing the offset. In abstract-tls/lib/abstract-tls.js there are some operations which create a new DataView just to read or write a single element; this isn't the correct usage. http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ may be a useful reference. If you're handling streaming data then presumably you're receiving multiple ArrayBuffers, one after the other. You should create one DataView per buffer. The only challenge is properly handling the boundary from one buffer to the next, if the boundary is within an element like a uint16 or uint32. -Ken -- -kg -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
Le 02/04/2013 04:24, Kenneth Russell a écrit : Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. When you are streaming things, what's the correct use of DataViews? ie : you are supposed to create each time you want to read some bytes a DataView (which can be optimized or whatever, but still with some costs)? Maybe it's outside of the scope of this discussion, I have already provided examples, I still suspect that I am using it wrongly or that ArrayBuffers are more adapted to webgl (ie static buffer manipulation) than network streaming (ie dynamic buffer manipulation). Probably I am wrong but really would like to know then what's the correct use. Regards, -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
I think one day I would have raised this subject too. While doing [1] to [3], I was wondering during some time if I was using typed arrays correctly, because I found strange to have to create each time a DataView of a possible enormous buffer to read 2 bytes, and what the impact on performances. Not talking about node.js that does not care about the fact that their DataView instantiation is ridiculously slow, it appears that the defect is present in FF too up to a certain version but it's corrected in the latest Nightly, so probably the answer is that there is an impact on performances. Maybe it's not uninteresting to look at [3] where I am trying to compare 3 methods (former string buffers, typed arrays without DataViews, and typed arrays with DataViews) Or maybe I am still not using this correctly, all protocols used here are in big endian order, I did not read everything about the subject and why this decision was made but the basic reflex would be to add an endianness option to typed arrays. Regards, [1] https://github.com/Ayms/node-Tor [2] https://github.com/Ayms/iAnonym [3] https://github.com/Ayms/abstract-tls and https://github.com/Ayms/abstract-tls#performances- Le 27/03/2013 01:18, Brendan Eich a écrit : Kenneth Russell wrote: On Tue, Mar 26, 2013 at 4:35 PM, David Hermandher...@mozilla.com wrote: [breaking out a new thread since this is orthogonal to the NaN issue] While the Khronos spec never specified an endianness, TC39 agreed in May 2012 to make the byte order explicitly little-endian in ES6: https://mail.mozilla.org/pipermail/es-discuss/2012-May/022834.html The de facto reality is that there are essentially no big-endian browsers for developers to test on. Web content is being invited to introduce byte-order dependencies. DataView is usually held up as the counter-argument, as if the *existence* of a safe alternative API means no one will ever misuse the unsafe one. Even if we don't take into account human nature, Murphy's Law, and the fact that the web is the world's largest fuzz tester, a wholly rational developer may often prefer not to use DataView because it's still easier to read out bytes using [ ] notation instead of DataView methods. I myself -- possibly the one person in the world who cares most about this issue! -- accidentally created a buggy app that wouldn't work on a big-endian system, because I had no way of testing it: https://github.com/dherman/float.js/commit/deb5bf2f5696ce29d9a6c1a6bf7c479a3784fd7b In summary: we already agreed on TC39 to close this loophole, it's the right thing to do, and concern about potential performance issues on non-existent browsers of non-existent systems should not trump portability and correctly executing existing web content. I am disappointed that this decision was made without input from both of the editors of the typed array spec and disagree with the statement that it is the right thing to do. First, my apologies to Dave for forgetting the May decision. I was looking in the wrong place for a record of that decision! Second, I understand Ken's point of view (old SGI hacker here) but have to question it on the grounds Dave raises: no one is testing, so there are very likely to be latent little-endian dependencies in deployed code today. So why not codify this? Because it might penalize big-endian systems? The IP protocols use big-endian byte order (owing to the pre-Intel big-endian architectures of IMPs and early Internet machines) and so penalize Intel machines, and we take the hit (and it's small on modern super-scalar CPUs). Ken, a couple of questions: 1. Do you know of any big-endian systems with market share that host JS implementations? It would be great to have a list. 2. Independent of the answer to (1), today's web browsers run on little-endian systems and that has very likely created a de-facto standard. If we codify it, we make the small to empty set of big-endian systems pay a price. Why is this the wrong thing for typed arrays but the right thing (in reverse! majority-architectures penalized) for the IP protocol suite? /be -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Le 22/03/2013 19:33, Mark S. Miller a écrit : On Fri, Mar 22, 2013 at 6:03 PM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). Are you referring to the function atLeastFreeVarNames at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/atLeastFreeVarNames.js? It does scan the source using regular expressions to look for all possible identifiers. But it doesn't do a full parse or even lex. As a result, it picks up identifiers in comments and literal strings as well. Security only requires that the code being scanned cannot contain have a free (and therefore global) variable reference without it being included in atLeastFreeVarNames's result. Yes, exactly, indeed it's not parsing but rexexpeing. But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Nothing official yet. But see https://code.google.com/p/google-caja/wiki/SES http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/37199.pdf Thanks, for [1] there is a script supposed to tame the page, trying to use a kind of home-made Object.observe which just shadows some DOM prototype properties and assign getters/setters, unexpectedly the behavior is different in each browser, and globally this does not work at all as such, maybe the override problem, more probably when I am back to it. [1] http://www.ianonym.com Regards, -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Regards, [1] https://gist.github.com/Ayms/2995641#another-approach-can-be-cajavm- Le 21/03/2013 22:17, Kevin Reid a écrit : Correction: On Thu, Mar 21, 2013 at 2:16 PM, Kevin Reid kpr...@google.com mailto:kpr...@google.com wrote: Yes. SES requires 'with' as a means to hook into 'global' variable reads and writes; without it, it is impossible without performing a parse and scope analysis of the code to be evaluated to emulate the semantics of browser global environments, such as in: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are frozen Objects faster ?
Typed Arrays are not frozen on FF, they are not extensible, only new
typed_array(nothing) is frozen (just bad luck for your example :-) ).
Reading this thread, it seems that I am not using good practices,
because I am using quite often the object literal indexed with numbers
(var a={};a[1]=something), and I am using delete to remove the values
(the object litteral becomes a kind of array with holes), and I really
expect delete to remove the property, not to assign it to null. I find
it convenient (despite of the fact that properties enumeration order in
that case is let to the appreciation of the js engine and can change
depending on what you are doing), is this not correct/impacting a lot
performances?
One day maybe there could be an annex in ES specs about good practices
and performances, or does it exist somewhere?
Regards,
Le 14/02/2013 21:50, Andrea Giammarchi a écrit :
I wodner how come Firefox behaves like that then but I don't have
tests to compare any difference between these two. I will write some,
thanks
On Thu, Feb 14, 2013 at 12:48 PM, Andreas Rossberg
rossb...@google.com mailto:rossb...@google.com wrote:
On 14 February 2013 21:36, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com
wrote:
Binary Arrays are indeed frozen objects, at least in Firefox,
and ultra
fast:
Object.isFrozen(new Float32Array()) // true in Firefox
Since these are ultra fast in Chrome too but not frozen, I
believe there is
already a way to speed up typed stuff (didn't check how it's
done though) so
I wonder how come Object.freeze() is not taking similar approach
typizing
behind the scene the object improving all static properties getters
(probably dropping those getters where possible unless defined
as such)
Frozenness is largely irrelevant for typed arrays, since all array
accesses are defined by a magic nameless getter/setter pair per the
WebIDL spec.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit : All the presentation decks from the meeting are publicly available at http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013 the short form: In ES5, today you can use Array.prototype as the [[Prototype]] of non-Array objects or apply the Array.prototype methods to non-arrays. The behaviors they get are non-necessarily what you would expect if you would really subclass Array. We need to preserve the existing behaviors for these existing use cases but would like to provide the more reasonable behavior when class extends Array is used to create a subclass. Array.prototype.concat is the most problematic of the existing methods in this regard. After reading this thread and the slides, what is the plan for Typed Arrays (dedicated array like methods or Array subclassed like) ? I see the constraints for subclassing, but the solution a.from(b,map) seems a little bit strange (even if I agree that it should return the same instance as a) , and what about concat, slice, etc as you mention? Couldn't we add something like a parameter to the methods : example.map(f,thisArg, true) or example.map(f,true) returns example's instance instead of Array (same processing as .of, .from), so you can explicitely say that you want to return the same instance and don't have backward compatilities issues (hopefully...) ? I have used a lot Typed Arrays for [1] [2] [3] and all along wondering why Array like optimized methods were not available, especially concat, and why it was speced entirely in TC39 while a spec already exists (which specifies slice/subarray but surprisingly not concat), but it will be extremely usefull to have the Array like methods in the ES specs for Typed Arrays. Regards, [1] https://www.github.com/Ayms/node-Tor [2] https://www.github.com/Ayms/iAnonym [3] https://www.github.com/Ayms/node-typedarray -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: bis - Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
and, I forgot and don't know exactly if this should fall here, a toString(encoding) method which supports streaming, see [3] using TextEncoder/TextDecoder Le 12/02/2013 12:54, Aymeric Vitte a écrit : Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit : All the presentation decks from the meeting are publicly available at http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013 the short form: In ES5, today you can use Array.prototype as the [[Prototype]] of non-Array objects or apply the Array.prototype methods to non-arrays. The behaviors they get are non-necessarily what you would expect if you would really subclass Array. We need to preserve the existing behaviors for these existing use cases but would like to provide the more reasonable behavior when class extends Array is used to create a subclass. Array.prototype.concat is the most problematic of the existing methods in this regard. After reading this thread and the slides, what is the plan for Typed Arrays (dedicated array like methods or Array subclassed like) ? I see the constraints for subclassing, but the solution a.from(b,map) seems a little bit strange (even if I agree that it should return the same instance as a) , and what about concat, slice, etc as you mention? Couldn't we add something like a parameter to the methods : example.map(f,thisArg, true) or example.map(f,true) returns example's instance instead of Array (same processing as .of, .from), so you can explicitely say that you want to return the same instance and don't have backward compatilities issues (hopefully...) ? I have used a lot Typed Arrays for [1] [2] [3] and all along wondering why Array like optimized methods were not available, especially concat, and why it was speced entirely in TC39 while a spec already exists (which specifies slice/subarray but surprisingly not concat), but it will be extremely usefull to have the Array like methods in the ES specs for Typed Arrays. Regards, [1] https://www.github.com/Ayms/node-Tor [2] https://www.github.com/Ayms/iAnonym [3] https://www.github.com/Ayms/node-typedarray -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises
I don't know when tasks.js will be usable (ie generators supported)
but probably it's a very good solution to solve all the async (and
resync) issues I had doing https://github.com/Ayms/node-Tor where
unexpected and unpredictable things as well as performances reasons
forced me to use [do_not_wait, setTimeout, clearTimeout,...] which makes
part of the code look like a mess and that I found not easy at all to
synchronize.
Le 13/11/2012 11:43, David Bruant a écrit :
Le 10/11/2012 03:14, Brendan Eich a écrit :
David Bruant wrote:
Personally, to synchronize different async operations, I've never
read code more elegant than what Q.all offers.
What about task.js's join?
https://github.com/mozilla/task.js/blob/master/examples/read.html#L41
I feel it's pretty much equivalent. Maybe slightly less verbose. I'd
write the same code with promises as:
Q.all(read(sleep.html), read(read.html)).then(function(f1, f2){
out.innerHTML += sleep.html: + (f1.responseText.length) +
\n;
out.innerHTML += read.html: + (f2.responseText.length) + \n;
});
Generators + promises = tasks ;-)
It took me several months to understand the value of tasks.js and then
I loved the idea (though I haven't used it because of the lack of
generators in platforms). The code you linked to leaves me somehow
uneasy, because it looks like sync code while it's async. Promises
have this advantage that they make clear what's sync and what's async.
But maybe I also need to step out of my comfort zone for this case...
What's the error forwarding/handling story for tasks?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: global object in strict mode
We don't know what name has 'global' (ie var global=this, var
window=this, etc)
This is what I tried to figure out here among others :
https://gist.github.com/2995641 (automatic global.global=global,
window.window=window), maybe impossible, unlikely, or whatever
I don't know well about this CSP proposal but it seems strange to me
everytime something states that 'eval' is forbidden or stuff like this,
a 'wrap' or equivalent would be better
Le 24/08/2012 19:51, Brendan Eich a écrit :
Kris Kowal wrote:
On Fri, Aug 24, 2012 at 10:41 AM, Brendan Eichbren...@mozilla.org
wrote:
I'm not sure what the problem is -- I read the old thread, and
noticed the
solution:
var global = Function(return this)();
This is good for any code mode, strict or non-strict. Does CSP ban
Function
as well as eval?
CSP does forbid the Function constructor, by the edict “Code will not
be created from strings”.
http://www.w3.org/TR/CSP/ Section 4.2 “If unsafe-eval is not allowed…”
Sure, makes sense (I think I even knew that once -- have to catch up
on CSP when I have some time, next millennium :-P).
Is it common to want an expression, usable in any context (non-strict,
strict, CSP, deep in a function nest with potentially many names in
scope, some of which might shadow globals), that evaluates to the
current global object?
JS libraries do things like
(funciton (global) {
// all the code here
})(this);
and that works, as well as the brute force
var global = this;
approach. But one must take care not to shadow the name.
Could ES6 add a predefined global property named 'global', set to
reference the global object? I suppose maybe - it would be writable or
(to use WebIDL's term) [Replaceable]. We can't just make a const
global, we will break extant code.
Is this global global important to standardize?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: July 25, 2012 - TC39 Meeting Notes
Le 28/07/2012 01:55, Rick Waldron a écrit : Explanation of specification history and roots in newer DOM mutation mechanism. AWB: Is this sufficient for implementing DOM mutation event mechanisms? RWS: Yes, those could be built on top of Object.observe Probably I must be misreading the proposal (again), but if you take a js DOM project where almost all attributes are handled via getters/setters, how can we observe something ? -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Updates to Object.observe
The goals of the proposal are indicated in the strawman but not the rationale. I am still wondering what I can observe in a DOM environment for example with the current proposal. Le 18/07/2012 22:19, Aymeric Vitte a écrit : I know this would induce other modifications in the specs but I am wondering why in the strawman examples o.x=6 does not notify (type=triggered or something like that), it does not modify the object but it could be interesting to get the notification t (document.body.innerHTML=xxx) Le 18/07/2012 01:49, Erik Arvidsson a écrit : We've done a bunch of updates to Object.observe in preparation for the next weeks face to face meeting. The updates are based on feedback from multiple people but more feedback is always welcome. http://wiki.ecmascript.org/doku.php?id=strawman:observe -- jCore Email :avi...@jcore.fr Web :www.jcore.fr Webble :www.webble.it Extract Widget Mobile :www.extractwidget.com BlimpMe! :www.blimpme.com -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Updates to Object.observe
I know this would induce other modifications in the specs but I am wondering why o.x=6 (strawman examples) does not notify (type=triggered or something like that), it does not modify the object's property but it could be interesting to get the notification too (document.body.innerHTML=xxx) Le 18/07/2012 01:49, Erik Arvidsson a écrit : We've done a bunch of updates to Object.observe in preparation for the next weeks face to face meeting. The updates are based on feedback from multiple people but more feedback is always welcome. http://wiki.ecmascript.org/doku.php?id=strawman:observe -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.download [was ...]
Le 12/07/2012 01:17, Jason Orendorff a écrit : On Mon, Jul 9, 2012 at 6:04 PM, Aymeric Vitte vitteayme...@gmail.com wrote: If the answer is that it is not possible because of the same origine policy, then it is not difficult to show that this policy can be broken already, by some manipulations, then it's better to have something clean. Please do explain what manipulations you have in mind here. As I understand it, the same-origin policy is what prevents other web sites you visit from sending HTTP requests to your bank (for example), with your login cookie attached, and looking at the responses. It seems like it would be a major security hole if that could be easily circumvented. -j Your example is specific, you need first to get the bank cookie which is not easy. More generally, MDN docs state : The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin. Then same MDN docs say : |window.postMessage| is a method for safely enabling cross-origin communication. Normally, scripts on different pages are only allowed to access each other if and only if the pages which executed them are at locations with the same protocol (usually both |http|), port number (|80| being the default for |http|), and host (modulo document.domain https://developer.mozilla.org/en/DOM/document.domain being set by both pages to the same value). |window.postMessage| provides a controlled mechanism to circumvent this restriction in a way which is secure when properly used. Then for example postMessage is breaking the first statement, not saying that it is not usefull, we did use it here http://extractwidget.com/#demo, you go on a site, inject the code, select your gadget and then via iframe and postMessage you login and record the gadget on our site, but which is secure when properly used indicates that some bad uses could be made. There is the cross domain xhr with access control too. But coming back to my point, I am not talking about a download like a xhr where you can set cookies, do post requests, etc, just a download that fetch the source, so I don't see it more dangerous than script or img fetching (or System.load) for example. -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.download [was ...]
Le 10/07/2012 13:40, Sam Tobin-Hochstadt a écrit : On Tue, Jul 10, 2012 at 7:36 AM, Aymeric Vitte vitteayme...@gmail.com wrote: Where System.eval does a simple eval if url is not a module. Right, that's what `loader.eval` is specified to do for module loaders. Where is it in the proposal ? I can not find it, what kind of eval does it do in that case ? What I see is : Reflective evaluation, via |eval| or the module loading API http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders starts a new compilation and linking phase for the dynamically evaluated code. As in ES5, the direct |eval| operator inherits its caller’s scope chain. But again, difficult to eval something that you can not fetch... -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.download [was ...]
Yes it's true, focusing too much on my needs, then forget it Le 13/07/2012 11:39, Jason Orendorff a écrit : On Fri, Jul 13, 2012 at 3:39 AM, Aymeric Vitte vitteayme...@gmail.com wrote: But coming back to my point, I am not talking about a download like a xhr where you can set cookies, do post requests, etc, just a download that fetch the source, so I don't see it more dangerous than script or img fetching (or System.load) for example. It's the difference between exposing every image on your intranet to any random web page that asks for it, and exposing all data on your intranet to any random web page that asks for it. Any web page could start by fetching http://intranet/; and follow the links from there. This kind of comprehensive spidering of an organization's internal data is obviously not possible with img. This is basic browser security stuff. I strongly suggest reading up before posting anything more on this topic. -j -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.download [was ...]
I have given some examples, surprising that nobody else reacts with
other examples. One of the use could be to be able to do the very simple
thing :
var f=function() {
var a={};
var cb=function(code) {System.eval(code);console.log(a.b)};
System.download(url,cb);
//url's code -- a.b='b';
}
Where System.eval does a simple eval if url is not a module.
Or something like that, why do we have the eval(src) possibility in the
proposal if we can not fetch src ?
Le 10/07/2012 01:48, Aymeric Vitte a écrit :
Le 10/07/2012 01:18, Sam Tobin-Hochstadt a écrit :
On Mon, Jul 9, 2012 at 7:04 PM, Aymeric Vittevitteayme...@gmail.com wrote:
I would like to have the final word on that one.
If the answer is that it is not possible because of the same origine policy,
then it is not difficult to show that this policy can be broken already, by
some manipulations, then it's better to have something clean.
The same-origin policy is not the responsibility of TC39, and more
importantly it's not something that I can speak with the requisite
authority about. Adding a convenience for fetching data using the
current fetch hooks of loaders is a possibility, but I don't want to
add more conveniences before it's clear they're useful.
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
System.download [was ...]
I would like to have the final word on that one. If the answer is that it is not possible because of the same origine policy, then it is not difficult to show that this policy can be broken already, by some manipulations, then it's better to have something clean. Le 06/07/2012 19:21, Aymeric Vitte a écrit : Le 06/07/2012 18:52, Sam Tobin-Hochstadt a écrit : On Fri, Jul 6, 2012 at 12:51 PM, Aymeric Vittevitteayme...@gmail.com wrote: OK, then are there objections to the async System.download(url,callback) ? This is just a version of XHR, but with a different cross-origin policy? Yes and the former unlikely. Why ? (Same origin policy ???) You said in a previous post : If you want the ability to fetch the source the way that the loader would do it, and then not actually *load* the code, we could potentially add that -- jCore Email :avi...@jcore.fr Web :www.jcore.fr Webble :www.webble.it Extract Widget Mobile :www.extractwidget.com BlimpMe! :www.blimpme.com -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
Le 06/07/2012 03:17, Brendan Eich a écrit : Aymeric Vitte wrote: Then the sync xhr is absurd ? It's a botch that developers avoid , else they jank the user interface. Yes, as far as you can or as far as you want to avoid unnecessary complication, for example projet [1] is loading quite a lot of things using xhr and scripts (which are loading others), the priority was to load the user interface as fast as possible (offline feature, etc), then most of the loadings are async but the sync xhr could not be avoided (easy way sometimes but as far as I remember not using it could lead to situations that looked unresolvable) We've been over this. Are you seriously defending it? Do we have a survey of the use of sync against async ? I think it would show that sync is much more used (wrongly or easy way again, but...). The possibility to have a sync xhr remains usefull, but I see that I will be opposed strong arguments (could not find previous discussions about it). If not possible, could we have at least a System.download(url,callback), as simple as just loading the url content and not caring about what is inside ? So we have an alternative to creating globals or linking to globals [1] : http://www.blimpme.com/mobile/ -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
Do we have a survey of the use of sync against async ? I think it would show that sync is much more used (wrongly or easy way again, but...). I completely disagree with this. Most developers without the knowledge/skill to know why sync is bad are just going to use a library like jQuery - which uses async. I'm not aware of any major library that uses sync as a default for their ajax api or uses sync in their own code. - Russ I am not refering to libraries but to developers/sites that indeed are using libraries and then feel (usually wrongly) necessary to extend it with unofficial/not good libraries or their own and then add some stuff around that usually is sync, as far as I saw debuging node-dom or looking at usual web sites -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
OK, then are there objections to the async System.download(url,callback) ? Le 06/07/2012 17:09, Russell Leggett a écrit : On Fri, Jul 6, 2012 at 10:58 AM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: Do we have a survey of the use of sync against async ? I think it would show that sync is much more used (wrongly or easy way again, but...). I completely disagree with this. Most developers without the knowledge/skill to know why sync is bad are just going to use a library like jQuery - which uses async. I'm not aware of any major library that uses sync as a default for their ajax api or uses sync in their own code. - Russ I am not refering to libraries but to developers/sites that indeed are using libraries and then feel (usually wrongly) necessary to extend it with unofficial/not good libraries or their own and then add some stuff around that usually is sync, as far as I saw debuging node-dom or looking at usual web sites I'm not saying people don't do it, I was saying that the percentage is likely far smaller than you claim. Perhaps I'm deluding myself. Anyway, I don't think we should cater to something that is considered bad practice. As Brendan has said, lets lead the horses away from the rotting vegetables with better carrots. - Russ -- jCore Email :avi...@jcore.fr mailto:avi...@jcore.fr Web :www.jcore.fr http://www.jcore.fr Webble :www.webble.it http://www.webble.it Extract Widget Mobile :www.extractwidget.com http://www.extractwidget.com BlimpMe! :www.blimpme.com http://www.blimpme.com -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
Le 06/07/2012 18:52, Sam Tobin-Hochstadt a écrit : On Fri, Jul 6, 2012 at 12:51 PM, Aymeric Vitte vitteayme...@gmail.com wrote: OK, then are there objections to the async System.download(url,callback) ? This is just a version of XHR, but with a different cross-origin policy? Yes and the former unlikely. Why ? (Same origin policy ???) You said in a previous post : If you want the ability to fetch the source the way that the loader would do it, and then not actually *load* the code, we could potentially add that -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
I don't understand your comment about `window` and `document`. They
are already globals in browser JS environments.
Please, take some time to read again my previous posts, I am refering to
both server side's and browser's env, with 'window' and 'document' that
are familiar as examples, but these could be 'mylocalvar1' and
'mylocalvar2' in both (and in my server side examples 'window' and
'document' are not supposed at all to be in fine globals)
As for async, there are a variety of ways to make it easier
No, the only way to ease your life is to define a lot of things as
globals which some people like myself might not want to do, same as var
script_=document.createElement('script') callbacks, modules are
reproducing the same
I don't know if you develop everyday async code handling multiple asyncs
stuff but it becomes all the time very quickly a nightmare
, but we
are *not* going to add synchronous IO as part of the module system.
The run-to-completion semantics of JS are non-negotiable.
Then the sync xhr is absurd ?
The non-negotiable word reminds me some famous vendor not implementing
the sync xhr for obscure purposes (not blocking the app or something
like this), I did not check since that time but I would bet they finally
implemented it
It is really needed and looks so simple, do we have to live forever with
the xhr limitations or can this simple thing be included ? (I understand
it does not follow the global logic of modules/loaders but there might
be a way)
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
This is not exactly what I would like to do, I would like to decide
where I want to run it and when (whether it's sync or async), the global
environment can be protected by strict mode now if you don't eval within it.
Basically I would like to have :
var code=download(url); //download(./my_server_secret_script.js)
//download(http://www.public_script.com/well_known_public_script.js;)
eval(code); //sync or asynch
The problem with the loader proposal is that you need a callback and it
only extends the global scope, so the loader does not know the
surrounding environment where it is called, example :
console.log(global);//global
var callback=function() {
var window=some window; //not a global var
System.load('script.js',function() {console.log(res)}; //script.js
-- var res=window.document.body
//crash
}
Real example here:
https://github.com/Ayms/node-gadgets/blob/master/lib/gadgets.js , section :
window=dom(page,null,options);
document=window.document;
document.onload=function() {
var EWA = require('ewa').EWA;
var ewa = new
EWA(!!params.gadget,!!params.price,params.search?params.search:false,ew,params.nbmax?params.nbmax:100);
'ewa' was a normal script that was transformed into a module (even if on
server side I could have loaded it and eval it (but with a callback),
let's consider the same case where I need a public script into the
browser), and 'window' and 'document' had to become super global vars
to make it work
Using System.load I don't have to transform the script into a module but
I still need to make 'window' and 'document' global vars, and I have now
to use a callback
Then why not just a System.download(url) ?
Note : the above case is the exact real life representation of what I am
trying to describe here : https://gist.github.com/2995641
Le 03/07/2012 21:06, Jason Orendorff a écrit :
On Tue, Jul 3, 2012 at 2:29 AM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
why can't we have in the module proposal (or somewhere) just the
possibility to load code and eval it (in browsers and server side
environments) ? ie why should I be obliged to transform my script
into a module and have to maintain both, or more if I want to
insure perfect compatibility ? The question is trivial and not
entirely related to modules or ES but since modules are
considered, why not adding this possibility now ?
Well, under the current proposal, you can say:
System.load(url, function () {}, function () {});
This will basically just load the given url and run it,
asynchronously. (The code is treated as a module, but IIUC the only
difference that makes is that global variables and functions it
defines won't pollute the global environment by default -- which seems
like a good thing.)
-j
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Static Module Resolution
It's confusing maybe because what I am requesting is very very basic
compared to modules/loader complexity and maybe I did mix it with an
example not so basic.
I just want something that loads the code and then I decide what to do
with it. Indeed on browser's side it would be like a cross-domain xhr,
this does not exist but since modules will exist into browsers too, why
not including this possibility ?
You are right, System.load(ewa.js, ...) would work, I did not say the
contrary but to make it work I need to define 'window' and 'document' as
global vars, I don't like it a lot if I care about separating contexts
and then I have a problem if I want to have several 'window' and
'document', and I have to use a callback (I know everything is based on
async but in some cases it's quite complicate to handle, then if things
can be sync that's not a bad thing)
Simply, something like :
{
var window=window1;
var code=System.download('ewa.js');
eval(code); //or whatever I like to do
}
{
var window=window2;
var code=System.download('ewa.js');
eval(code); //or whatever I like to do
}
Le 04/07/2012 15:39, Sam Tobin-Hochstadt a écrit :
I'm slightly confused about what you want here. If you just want the
ability to download code, and then eval it using the loader mechanism,
that's already there -- just use XHR to get the code, and then call
`System.eval(...)`. If you want the ability to fetch the source the
way that the loader would do it, and then not actually *load* the
code, we could potentially add that, but it's tricky for recursive
cases -- would you want all the relevant code, or just the specified
module? Or do you want something else than this? Finally, I don't see
why your example doesn't work exactly as: document.onload(function() {
System.load(ewa.js, ...); })
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Fwd: Re: Static Module Resolution
Forgot to copy the list... Message original Sujet: Re: Static Module Resolution Date : Tue, 03 Jul 2012 09:27:50 +0200 De :Aymeric Vitte vitteayme...@gmail.com Pour : Brendan Eich bren...@mozilla.org Copie à : Kevin Smith khs4...@gmail.com Le 02/07/2012 20:09, Brendan Eich a écrit : Again, sync loading is anathema in the browser. Any require usage must be (1) callback-based, or else (2) based on a preprocessor (if not full CPS-transforming compiler). In case (1), let's say the underlying system (AMD) uses XHR and eval. The March meeting's resolution would throw an early error (early in the eval's phase structure, later in the script's phase structure) on any import syntax in the eval'ed program. In case (2), the require dependency is loaded before runtime, one way or another. If the compiler generates ES6, no problem. If it generates ES5, also no problem (ES6 - ES5 compilation entails compiling import into something like what require compiles to). /be All this is logical, today we have the situation of scripts (sync) loading scripts (async) which is not really nice to handle, the debate here was about compatibility between require and import, now what about normal scripts (ie non modules), why can't we have in the module proposal (or somewhere) just the possibility to load code and eval it (in browsers and server side environments) ? ie why should I be obliged to transform my script into a module and have to maintain both, or more if I want to insure perfect compatibility ? The question is trivial and not entirely related to modules or ES but since modules are considered, why not adding this possibility now ? -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules: use of non-module code as a dependency
I think I have already raised 10 times at least the fact that the
current module proposal does not allow to load a non module so both are
complementary and can interact between each others.
script .. is not available in non browsers environments
and 3) is unnecesary complicate
Le 30/06/2012 20:19, David Herman a écrit :
On Jun 30, 2012, at 11:06 AM, James Burke wrote:
Possible answers:
1) Unsupported. Error occurs.
2) jQuery is suggested to provide a jquery.es.js file that uses the
new keywords.
3) Proposed: When jquery.js is compiled, and no import/module/export
modules are found, then the Loader will execute jquery.js to see if it
exports a value via a runtime API. It uses that value to then finish
wiring up the local jQuery reference for module foo.
I'm curious why you didn't include what seems like the most straightforward
answer to me: jQuery continues to work as it did before, and just like always,
you include it via a script tag and subsequently access it as a global:
script src=jquery.js/script
script
... $('#foo').blah().blah() ...
/script
I'm wondering why you didn't include this option -- is it just because jQuery
is a special case that creates globals, whereas you also want this to work for
modules that don't create globals?
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
I think we all agree that global isolation is the core purpose of a module system. (Is that incorrect?) Partly agree? I believe that obviating the *need* for globals is the core purpose of a module system. I don't believe that modules should necessarily be strictly separated. Modules should be given clean local scopes so that they don't overwrite each other, but that doesn't mean they shouldn't be able to still communicate via the global object. Yes, exactly, if I can dare a comparison, a module could behave somewhere like the theorical 'wrap' here https://gist.github.com/2995641 (sorry to bother with this), contexts are separated, you can not create global vars inside the 'wrap' but can access them, you decide what should come into the 'wrap' and what goes out, so what you can/want to share, a bit like having a super global outside and multiple globals inside the 'wraps' (or modules) -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
Le 26/06/2012 20:54, Isaac Schlueter a écrit : The linked blog post is a very rough cut of where my thoughts are on the subject. Expect changes and cleanup. It does not represent a fully-baked (or even half-baked) idea, but more like a general direction. I expect to clean it up and propose something at least half-baked to this list soon, incorporating some of the feedback that I've gotten from that blog post. ... If we can focus what we do on the things that are very essential to what we need, we can probably beat those odds :) Regarding modules I don't know right now what would be the best in terms of syntax. Node.js's way is good, except the transitive dependency issue mentioned in your post which in some cases indeed can cause problems. I had some hard time to get used to this commonjs/node.js way of separating modules which can not interact between each others, but now I don't find it bad (even good). What I find bad (1) is the need of VMs, let's take node.js's one, it's calling c++ stuff, calling itself js's stuff, and at the end things are coming back to js (with some imperfections like node.js's VM not binding things correctly in some cases) And what I find bad (2) is that the fact that a module could be a normal web js code (ie not a module, the web is composed of js code, not modules) seems to be minimized, and (3) why should we continue to load cross-domain scripts via the script .. tag using onload to get the result (normal browsers) or onreadystatechange (abnormal browser) and then process it via global variables ? Using xhr for example (var code=xhr_result(xxx);eval(code)), this breaks the same origin policy but it's already broken by the capability of inserting scripts (then I am not sure about your proposal In Web Browsers with script..). And what I find bad (4) is the impossibility of wrapping things as I describe here https://gist.github.com/2995641 (maybe impossible, but at least it shows the idea, and the need) instead of being forced to transform js code into modules and play with globals, bindings and clone stuff. -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
I guess the grep work is not easy to do, but I have tried (manually) to find ?. or ?( in coffee script projects, trying to seek into projects of main contributors. Maybe not lucky or not really aware of the most popular projects, but I did not find any up to now. According to my previous posts I am quite convinced it has an interest, I remain perplex regarding the use of ?( , then, I am really curious to see CS's uses, could you please highlight some projects ? Le 21/06/2012 05:54, Jeremy Ashkenas a écrit : As requested, running those rough greps again on the top ten most popular CoffeeScript repos on Github yields: 188 uses of object?.property 32 uses of object?[key] 50 uses of function?(args) 46 uses of variable ?= value ... and the other ones are a bit tricker to grep for. There are at least a handful more uses of the `function?(args)` style but with implicit parentheses: `function? arg1, arg2` ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
When I made that one : https://github.com/Ayms/node-dom it was supposed
to be a fast and minimal implementation of the DOM, so it works in
almost all real cases and do not crash in other situations.
The result is not bad but not as fast as expected neither minimal. Not
minimal because I had to adapt to plenty of frameworks or sites's
specific stuff but widely used. Not as fast as expected because I think
property access is too slow (styles lookup for example for this project,
it seems that the problem increases exponentially when trying to access
undefined properties), I thought maybe it would be possible to implement
virtual rendering but I had to surrender, no way today to do this in js
I believe, it would be too slow, but maybe tomorrow if I read correctly
this thread.
Regarding NodeLists, it's not an ES subject but I would say :
1- the world thinks it is an array
2- the world does not know it is updated dynamically (in an ordered
way in addition ...)
As everybody I made my own NodeList (and other things such as
CSSStyleDeclaration), not exactly w3c, which is to make it look like an
array (like everybody again and future DOM specifications), so 1) is solved
But 2) (which is the dynamic ordered update of NodeLists) still
continues to look useless to me and a huge handicap for performances, I
suppose plenty of people will disagree, probably a question of
experience, unlike jquery for example I never or rarely uses/used
NodeLists and probably jquery users or just normal developers recall
several time $('xx') or document.getElement(s)Byxxx, the question here
has nothing to do with ES but is it really fundamental ?
Le 19/06/2012 17:37, Allen Wirfs-Brock a écrit :
On Jun 19, 2012, at 5:29 AM, David Bruant wrote:
Le 19/06/2012 14:11, Alex Russell a écrit :
...
is to give us a chance to fix this (among other) errors in DOM's design. Yes,
it's up to DOM to fix it, but we need ES to adopt things like Allen's Object
Model Reformation to help enable it:
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
I guess knowing what the elem.find() API is will help me understand this part
better, because I'm not sure I see the link between the object model
reformulation and fixing the DOM API. Can you elaborate further on that? (if
this discussion already happened somewhere else, a link to that discussion will
be enough, of course)
Actual API design is probably an orthogonal issue. What the Object Model Reformation proposal (which is
probably better understood by its subtitle Decoupling [ ] and Property Access) does is permit the existing behavior
of DOM collections to be directly expressed in JavaScript without having having to resort to host object magic. It supports the
general principle of: If the DOM needs to do it then it should be doable in pure JavaScript. There are lots of reasons why for
some objects it makes sense for indexed access to have different semantics than property access. The DOM
does this today. In an improved DOM API design it will probably also be the case. The Object Model Reformation provides a
semantic basis for designing such improved APIs rather than just making up host object magic that has no foundation in core
JavaScript semantics.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Complement for my last sentence : if you are using ?. it means that you don't know if the thing does exist, then you are probably waiting for it to exist (asynchronous environments for example), then once you get it, it is very unlikely that you call it right away, I would like to see some examples Le 20/06/2012 00:36, Aymeric Vitte a écrit : Coffeescript seems to have some radical behavior (a.b?.c.d.e.f) a bit similar to what I suggested (which ok can not be in js) But the discussion here still does not say how much a.b?() or a.b?.call(xxx) is used in coffeescript Personnaly I was thinking that ?. should more allow to check existence rather than both checking and calling it if it exists, difficult to win everywhere Le 19/06/2012 22:35, Allen Wirfs-Brock a écrit : On Jun 19, 2012, at 12:37 PM, Jeremy Ashkenas wrote: On Tue, Jun 19, 2012 at 3:33 PM, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: foo.bar?(args) == foo.bar?.call(foo, args) fun?(args) == fun?.call(undefined, args) How are these equivalent? Won't fun?.call evaluate to undefined if fun is undefined and undefined(undefined,args) will throw... ... check out the compilation: http://coffeescript.org/#try:fun%3F.call(undefined%2C%20args)%0A%0Awindow.method%3F.call(window%2C%20args) http://coffeescript.org/#try:fun?.call%28undefined,%20args%29%0A%0Awindow.method?.call%28window,%20args%29 Ah, interesting...so this is actually close to what I was advocating for this particular case. However, if I now understand correctly you are saying that fun?.call() produces undefined if fun is null/undefined but will throw if fun is defined as: fun = new Object; because it doesn't have have call property. Also, it isn't clear to me why the second example (window.method?.call(window, args)) is only guarding for null and not undefined. Is it only because you guard for undefined on variable references and not on property references? Basically, I see what the code you generate is doing but the unlying semantics that yields that code is less obvious. It doesn't eagerly evaluate to undefined ... the value of the *entire* expression is undefined if the chain is broken at the existential operator. That's much of the point of soaks: object.property?.i.can.keep.chaining.in.here.without.throwing.errors.if.property.is.undefined ;) Ah, again. I don't think Brendan's strawman will produce that result. The ...?.i is going to get undefined when it does GetValue on the Reference produced for object.property. Then undefined.can will throw in step 5 of 11.2.1 because the LHS is undefined. Getting this behavior seems to requires modifying . as well as defining ?. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email :avi...@jcore.fr Web :www.jcore.fr Webble :www.webble.it Extract Widget Mobile :www.extractwidget.com BlimpMe! :www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
This is related to what I was trying to figure out in the more fun with undefined thread, maybe it is wrong or have too many impact but I was about to suggest : 8.9.1 GetValue (V) ... 5. If IsUnresolvableReference(V), return undefined 11.2.1 Property Accessors Runtime Semantics: Evaluation ... 3. If baseValue is an abrupt completion or undefined, return baseValue. Why not, instead of adding ? operator ? Le 18/06/2012 07:11, Brendan Eich a écrit : Sorry, meant to start a new thread for: http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator As the Syntax section hints, we can't also adopt CoffeeScript's ?( variant, which enables foo.bar?(args, go, here).baz and the like. The C syntax heritage prevails. /be Brendan Eich wrote: David Herman wrote: On Jun 15, 2012, at 5:57 PM, satyr wrote: On Sat, Jun 16, 2012 at 4:33 AM, David Herman dher...@mozilla.com mailto:dher...@mozilla.com wrote: As for null, I can see how there's confusion about whether to use null vs undefined, and so I can see why CoffeeScript would just try to blur the distinction between them. Not just for blurring. Rejecting `null` is essential for CoffeeScript's existence due to `?.`, the soak/safe access operator. I think you could make a case for ?. defaulting for both but ?? defaulting only undefined. The case goes something like this: - The purpose of ?? is to provide a default value when no value was provided. The way to say no value in JavaScript is undefined. - The purpose of ?. is to fail soft when doing a property lookup. Both null and undefined throw when doing a property lookup. Agreed. This is one choice, it's plausible because of the distinction between defaulting (which requires intentional passing of a please default sentinel value, or not passing a trailing actual argument) and soaking up null-or-undefined. Yes, we could make ?? and ??= do the same for null as for undefined. I'm not sure that's the right choice, but it's a choice. For foo.bar?.baz, though, the clearer choice is to avoid throwing, which means evaluating to undefined if foo.bar is missing (evaluates to undefined) *or* has a value not coercible to object type (null or undefined). See http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator /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 -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
OK, ?. is enough and good Le 18/06/2012 16:48, Brendan Eich a écrit : Aymeric Vitte wrote: Why not, instead of adding ? operator ? You mean ?. here, I assume. The answer is because what you propose is an incompatible change to ECMA-262 (all editions) and JS back to its birth, which lets programs that throw currently continue to run, with possibly disastrous consequences (undefined flowing into the bank-balance database as NaN). There is no way that this kind of potentially-bug-hiding behavior should be the default semantics. It must be explicitly opted-into via new syntax. /be -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Yes, what I mean is that I did not see since a long time something like a===null?b:c or if (a===null)||b, and except for specific use like Object.create(null) I don't see a lot of null being used, then making the distinction for ??, ?: and others looks too subtle Le 15/06/2012 04:20, Brendan Eich a écrit : On Jun 14, 2012, at 6:38 PM, Aymeric Vittevitteayme...@gmail.com wrote: Maybe I missed it, never saw the use of null since a long time, but I can be wrong As Allen pointed out, null is specified in ECMA-262, e.g. Object.getPrototypeOf. /be -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
Probably there are very good reasons but I reask the question : why
should the attempt to access a property of a variable equal to undefined
global property not return undefined global property ? (ie a way that
this works : if (a.b.c.d) {} when a,a.b, etc are not set)
This can be usefull when things get loaded asynchronously and then when
you don't know when it will be available (it does not happen every day,
but in some cases you don't have necessarily a callback or an event to
tell you and then asynchronous stuff can start being extremely difficult
to handle).
Example :
console.log(a);//Reference error, GetBase returns undefined
console.log(window.a);//undefined
-- does not seem very logical, no ?
Maybe it was discussed thousand of times, but why not :
8.9.1 GetValue (V)
...
5. If IsUnresolvableReference(V), return undefined
Le 15/06/2012 01:22, Allen Wirfs-Brock a écrit :
On Jun 14, 2012, at 3:49 PM, Rick Waldron wrote:
On Thu, Jun 14, 2012 at 5:35 PM, Thaddee Tyl thaddee@gmail.com
mailto:thaddee@gmail.com wrote:
On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
This is a different issue, but I wonder how badly the web would
break if we
made undefined a reserved word. Does anybody in JS really
declare a
different local binding for undefined? In ES5 we got away with
making
undefined read-only. Maybe we should continue pushing and see
if we can
eliminate the rebindable undefined hazard.
JQuery [1] famously has an undefined parameter, like so:
(function( window, undefined ) { ... }(window))
Actually, this exists because undefined wasn't reserved. We would
certainly remove the formal param in favor of an reserved undefined.
Unfortunately, we can't take it back in extant code.
A wonder if this wart is hairy enough, that we wouldn't be justified
in some explicit backwards compatibility hackery in the spec. to
remove it.
For example, we could allow it to appear in parameter lists and
provide a dynamic check to ensure that nothing (other than a real
undefined) is passed. Similarly we could explicitly allow:
var undefined;
Certainly there is no particular reasons we need to allow:
let undefined;
const undefined=true;
class undefined extends foo { }
or any other new binding forms redefining undefined.
Allen
Rick
What would happen in this case?
[1] http://code.jquery.com/jquery-1.7.2.js
___
es-discuss mailing list
es-discuss@mozilla.org mailto: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
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
I am not talking about defining implicit properties or such things,
neither having undeclared stuff looking declared, but just changing the
behavior of retrieving a property when base is undefined, which will
then be undefined.
If am I reading correctly the specs, doing this change will work for
a.b.c.d, because undefined is returned first and nothing is set
anywhere, unless I am wrong :
console.log(a); //reference error
var a;//undefined
console.log(a.b);//reference error
will become :
console.log(a); //undefined
var a;//undefined
console.log(a.b);//undefined
Le 15/06/2012 15:52, T.J. Crowder a écrit :
On 15 June 2012 14:34, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Example :
console.log(a);//Reference error, GetBase returns undefined
console.log(window.a);//undefined
-- does not seem very logical, no ?
To me this would be a big step backward, after the very large stride
forward this group made in ES's strict mode of making _assigning_ to
an unresolvable reference an error rather than an implicit creation of
a property on the global object.
For one thing, how is the engine to know that the `a` in question was
meant to be `window.a`? Maybe I just forgot to put `var a` in the
current scope. (In fact, that's usually what it is when I get this error.)
Scope is not the same as an object (although of course, the scope
chain is conceptually made up of binding objects). If I refer to `a`
in my code and `a` has never been declared, that's a bug, and as I
haven't told it, the engine has no way of knowing what level in the
scope chain I intended `a` to be in. If I access the `a` property of
an object, and the property has never been defined, that could just be
lazy initialization; the engine knows that I'm talking about that
specific object (or its prototypes), because I've told it what object
to look at.
Separately:
(ie a way that this works : if (a.b.c.d) {} when a,a.b, etc are
not set)
Making the initial `a` evaluate to `undefined` wouldn't make that
work: Instead of the ReferenceError, you'd get a TypeError (cannot
read property `b` of undefined).
-- T.J.
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Before... I put Rick's answer below too, in strict/correct code it can be used but what examples (except yours) ? Maybe I missed it, never saw the use of null since a long time, but I can be wrong Do you think it does worth the complexity for the operators we are talking about ? w3c is forced to define something as null, would look strange and not serious to define it as undefined in specs, but in reality this is let to the appreciation of developers (who usually don't care), and for comparisons/default, null will, I think, never be used, then it should probably behave the same as undefined Le 15/06/2012 01:12, Tab Atkins Jr. a écrit : On Thu, Jun 14, 2012 at 4:06 PM, Aymeric Vittevitteayme...@gmail.com wrote: Nobody (except w3c) is using null, or when someone is using it, it is the same way as undefined, and it is not explicit (ie a||b or a==b, not a===null), I remind some old code where we could see the use of null but can not find a single example of recent code, then the new operator(s) should treat it the same way I believe, the problem is 0 here Your experience isn't necessarily universal. I've used null before to mean something different than undefined. ~TJ There doesn't need to be an explicit check for undefined - anytime null is used as an intentional place holder and its value would be _otherwise_ undefined counts as well. And for your information, I am not w3c and I use null frequently (the same way w3c uses it). -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Just to be clear I am talking about the use of null in the scope of the current discussion (ie operators/default) only Le 15/06/2012 01:37, Aymeric Vitte a écrit : Before... I put Rick's answer below too, in strict/correct code it can be used but what examples (except yours) ? Maybe I missed it, never saw the use of null since a long time, but I can be wrong The difference is known, do you think it does worth the complexity for the operators we are talking about ? w3c is forced to define something as null, would look strange and not serious to define it as undefined in specs, but in reality this is let to the appreciation of developers (who usually don't care), and for comparisons/default, null will, I think, never be used, then it should probably behave the same as undefined Le 15/06/2012 01:12, Tab Atkins Jr. a écrit : On Thu, Jun 14, 2012 at 4:06 PM, Aymeric Vittevitteayme...@gmail.com wrote: Nobody (except w3c) is using null, or when someone is using it, it is the same way as undefined, and it is not explicit (ie a||b or a==b, not a===null), I remind some old code where we could see the use of null but can not find a single example of recent code, then the new operator(s) should treat it the same way I believe, the problem is 0 here Your experience isn't necessarily universal. I've used null before to mean something different than undefined. ~TJ There doesn't need to be an explicit check for undefined - anytime null is used as an intentional place holder and its value would be _otherwise_ undefined counts as well. And for your information, I am not w3c and I use null frequently (the same way w3c uses it). -- jCore Email :avi...@jcore.fr Web :www.jcore.fr Webble :www.webble.it Extract Widget Mobile :www.extractwidget.com BlimpMe! :www.blimpme.com -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Indeed, maybe both should be included.
What about this case :
if (typeof(api)==undefined) {try later} else if (!api.a) {try later}
else if (!api.a.b)) {try later} else if (etc...)
which can be written : if
(!(((typeof(api)!=undefined?api.a:undefined)?api.a.b:undefined)?api.a.b.c:undefined))
{try later}
but can't be written with ?:
The best in that case would be to be able to do : if (!api.a.b.c) {try
later}
Why in accessors the attempt to access a property of |undefined| could
not return |undefined| itself ?
Le 13/06/2012 09:45, T.J. Crowder a écrit :
On 13 June 2012 06:52, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
People don't default on the caller side (at the callsite) much, in
my experience. Dave may be seeing other sources, but it's
extremely rare in my experience to see
I'm with Dave on this, I do it fairly regularly, usually when a
function turns around and calls another one with the arg and has no
other use for the arg:
function doSomethingNifty(a, b) {
return doSomethingVerbose({
x: 1,
y: a,
z: b ?: 5
// ...
});
}
?= looks great, and Wes' point about confusion re ||= (or even |||=)
and boolean logical operators definitely kills my preferred ||| for
the non-assignment form if there's going to be an assignment form --
and we all want an assignment form.
Is the reason for using ?: rather than ?? because we may want it for
my desired second ternary? E.g., from my other message:
a = b ?? c : d;
meaning
a = b !== undefined ? c : d;
Or that we want it (now, or in reserve) for something else? Because if
not, I'd prefer to see ?? rather than ?:. It's easier to type and the
double ?? calls back to the related ||. But again, only if we don't
want ?? (now, or in reserve) for something else.
Very much looking forward to ?: (however we spell it) and ?=.
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Typo below, I meant which can be written : if
(!(((typeof(api)!=undefined??api.a:undefined)??api.a.b:undefined)??api.a.b.c:undefined))
{try later}
Le 13/06/2012 12:12, Aymeric Vitte a écrit :
Indeed, maybe both should be included.
What about this case :
if (typeof(api)==undefined) {try later} else if (!api.a) {try later}
else if (!api.a.b)) {try later} else if (etc...)
which can be written : if
(!(((typeof(api)!=undefined?api.a:undefined)?api.a.b:undefined)?api.a.b.c:undefined))
{try later}
but can't be written with ?:
The best in that case would be to be able to do : if (!api.a.b.c) {try
later}
Why in accessors the attempt to access a property of |undefined| could
not return |undefined| itself ?
Le 13/06/2012 09:45, T.J. Crowder a écrit :
On 13 June 2012 06:52, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
People don't default on the caller side (at the callsite) much,
in my experience. Dave may be seeing other sources, but it's
extremely rare in my experience to see
I'm with Dave on this, I do it fairly regularly, usually when a
function turns around and calls another one with the arg and has no
other use for the arg:
function doSomethingNifty(a, b) {
return doSomethingVerbose({
x: 1,
y: a,
z: b ?: 5
// ...
});
}
?= looks great, and Wes' point about confusion re ||= (or even |||=)
and boolean logical operators definitely kills my preferred ||| for
the non-assignment form if there's going to be an assignment form --
and we all want an assignment form.
Is the reason for using ?: rather than ?? because we may want it for
my desired second ternary? E.g., from my other message:
a = b ?? c : d;
meaning
a = b !== undefined ? c : d;
Or that we want it (now, or in reserve) for something else? Because
if not, I'd prefer to see ?? rather than ?:. It's easier to type and
the double ?? calls back to the related ||. But again, only if we
don't want ?? (now, or in reserve) for something else.
Very much looking forward to ?: (however we spell it) and ?=.
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email :avi...@jcore.fr
Web :www.jcore.fr
Webble :www.webble.it
Extract Widget Mobile :www.extractwidget.com
BlimpMe! :www.blimpme.com
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [ANN] JSFixed recommendations document
Comments:
- fat arrow : I am not a fan of the syntax but it is usefull and does
fix the unlogical behavior of |this| (the rules are the same for the
|this| binding, it does not change except that you must apply it to the
surrounding environment), the thin arrow (as soft binding's use I
suppose) looks to be a concern of jquery people only
- Object.extend : too complicate if we see all the discussions around it
(Put/defineProperty), should be replaced maybe by an
Object.make(proto,props) or even an Object.clone
- Existential operator : good idea, I thought (maybe wrongly) that
undefined.a should be undefined (then undefined.a.b.c is undefined), we
encounter it everyday, the ?? proposal does not fix everything, now the
case we can think about is when you load an API which loads scripts that
are loading others asynchronously. Then you can never know when you
api.a.b.c (or one of them) will be available, then you do :
if (typeof(api)==undefined) {try later} else if
(typeof(api.a)==undefined) {try later} else if
(typeof(api.a.b)==undefined) {try later} else if (etc...)
instead of :
if (typeof(api.a.b.c)==undefined) {try later} else {do the job} or if
(!api.a.b.c) {try later} else {do the job}
Le 07/06/2012 22:27, Anton Kovalyov a écrit :
Hi,
When Angus first published his blog post some people got the
impression that we're trying to either discredit TC39 and its efforts,
or to replace it with our own committee. We value TC39 and feel like
they are doing a great job and we have absolutely no interest in
starting another committee or writing our own JavaScript spec. The
goal of JSFixed was to collect feedback from interested developers and
present it as a list of recommendations. And today we're publishing
the first such
document: https://docs.google.com/document/d/1JPErnYlBPG26chTuVSnJ_jqW4YkiQhvWn-FxwwsmkEo/edit
We hope that both the committee members and outsiders will find this
document useful. Let us know (here, on Twitter or on Github) if you
have any questions or comments.
Thanks,
Anton
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `with` revisited and related to object extension literals
No, you are not alone. Mustache and cascade are interesting but maybe not extremely, extremely usefull. Then as people have tried since years, I did write too a 'with'-like proposal in strict mode, I already sent it some time ago and got 0 feedback, maybe I did not present it the right way, it has almost nothing to do with the usual 'with' (which I find so strange that could never figure out how this could be used), it's somewhere the contrary, the concept is about the ability of binding things simply, not about making incredible mix-up of accessing/defining properties/var/bindings, so here it is again, not sure it can fit what you want but I have added more examples to show what it could simplify, and changed the title, it's not a 'with' revival, but a 'with' redesign, and then if 'with' is confusing (or not liked) it can be called another name : https://gist.github.com/edd064e5b29e67ebe493 It's a modest 'essai' (perfectible, maybe containing wrong or impossible things) so if it has to be destroyed, please be a little indulgent, at least I don't think one could say that the concepts behind it are not (very) usefull. Le 01/06/2012 12:09, T.J. Crowder a écrit : On 1 June 2012 06:05, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Brendan Eich wrote: you're just rehashing a concern based on appearances which (I want to be clear; sorry for harshing on the 'with' point) is a valid concern. We should discuss it directly, no 'with'-semantics mixed in. /be Yes, very useful. I'll stick to things like to me, the syntax makes it look like those identifiers would be resolved via the scope chain and such. Won't mention `with`. I'm a bit worried that people may have thought I was being derisive by talking about `with`, and that that may have raised hackles. I wasn't. I don't think `with` is a flawed concept at all (I recognize many do), so I don't use it derisively. I agree with, I think, the majority here including (if I'm not mistaken) your own good self that JS's original `with` had serious issues, which in my view were down to it using freestanding identifiers, intermixing object property resolution and scope chain resolution. But I have no problem with the _concept_ in a different form. So in summary and (largely) in closing: 1. I quite like the _idea_ of the cascade proposal, because like Dave (I think?) I find the way cascades are currently done (a'la jQuery, via `return this`) less than ideal. 2. My concerns with it relate to freestanding identifiers and how that _looks_. See earlier note to Dave. 3. I think that concern can be dealt with without going to a `with`-like structure. 4. I also think they could be dealt with via a new `with`-like structure that did not put an object at the top of the scope chain, but instead introduced a placeholder token for the object reference as purely syntactic sugar (~. or similar). To me there's a lot of use there, including cascades. But I seem to be alone. :-) I find that a bit odd, given how similar to that the goals of the cascade sugar seem to be, but if I'm on my own, I'm on my own. Best, -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New Object Extension Literal Strawman
I really like(d) the mustache proposal but unfortunately reached the
same conclusion : too complicate and confusing for what it brings. It's
surprising that the fundamental difference between Put and DOP was
unknown from almost everybody (including myself), then a rapid and easy
conclusion knowing that DOP is not very used could be : eliminate DOP,
but it's not possible, one of its purpose is to avoid modifying again
the prototype properties as could do the json attack described in the posts.
Anyway, the discussion slipped to the technical aspects only, then
before imagining tons of syntax possibilities, maybe the use should be
considered (normal use, not super and more complicated things), simple
example :
div.style.{width:0,cssText='xxx'} or div.style.{width:0,cssText:'xxx'} ?
How from a developper perspective do I know if cssText was defined
inside CSSStyleDeclaration prototype or via outside getters/setters ???
Will I have to think about that each time I am using mustache ?
Then to secure it I would be enclined to use always =, which could
look strange and confusing to normal developpers.
It's true that it can be compared somewhere to 'with' statement which is
almost never used because maybe not so usefull and everybody stated that
you can easily make a mistake, maybe the same may apply to mustache
Le 31/05/2012 11:35, Andreas Rossberg a écrit :
On 30 May 2012 22:33, Mark S. Millererig...@google.com wrote:
My concern is indeed the overall complexity budget. And I agree. I'm happy
to have both of these if we can make some real complexity cuts elsewhere. I
look forward to that other conversation ;).
I have the same concern. The syntactic complexity and subtlety of this
proposal seems relatively high for the limited value it provides. If
we are going to have class syntax anyway, I doubt that mustache or any
of its variants will see enough use to warrant adding it as well.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing built-in constructors
Le 26/05/2012 22:01, Brendan Eich a écrit : Domenic Denicola wrote: Is there a parallel to be drawn with __(define|lookup)(Getter|Setter)__, or is __proto__ different? I quite liked Allen's blog post about why IE decided to never support them [1]. Following that reasoning seems to lead to specifying Object.setPrototypeOf as a __proto__ replacement, No. First, you missed Mark's argument that I paraphrased against a per-frame (window, global context) static method, which David Bruant acknowledged in this thread just eight messages back: Once we're at it, for the sake of completeness there is probably no harm in adding a Reflect.setPrototype at this point, is there? There is, just as there's a cost to Object.setPrototypeOf (the obvious place to put it to match Object.getPrototypeOf from ES5). Mark pointed out that he'd have to delete that static method too, and from every frame that might run SES code. But when mashing up SES and non-SES code, it would be better not to break the non-SES code by such deletion. Having only the SES environment's Object.prototype.__proto__ to delete is better. And I realize that the new hazard is not due to __proto__ in itself, but rather to the capability of arbitrarily changing the prototype of an object, so adding an Object.setPrototypeOf really is a step backward. David If I understand correctly the SES issues are linked to the capability of being able to modify the [[prototype]] internal property of an existing object, that's why it did not surface with the triangle proposal (because a new object is created) Then what about something doing : obj = Object.create(proto,obj's properties) instead of obj.__proto__ = proto or setPrototypeOf ? Where obj's properties are handled internally -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: minutes, TC39 meeting Tues 5/22/2012
Le 23/05/2012 22:30, David Herman a écrit :
- I will be redoing the entire wiki to focus on community first, committee
second, and to make the big picture clearer
I know writters don't have always time but maybe adding more examples
and simple ones (even not reflecting the whole picture) in the strawmans
would help a lot. For example the fat arrow strawman is very condensed
for what it brings and it took some time before I start understanding
what the soft binding strawman was about. Example of simple examples
(hope this is correct) :
Soft binding :
var o={
msg:'I am o',
log:console.log(this.msg)
}
var o2={
msg:'I am o2'
}
o2.log=o.log;
o2.log();//I am o
//without soft binding it should be I am o2
Lexical this (and dynamic this) :
var test='aaa';
var o={test:'bbb'};
var o2={test:'ccc'};
//without lexical this
o.m=function() {var self=this; var func=function()
{console.log(this.test+' '+self)};func()};
var f=o.m;
o2.m=o.m;
o.m();//aaa bbb
//this.test is not o.test
o2.m(); //aaa ccc
//this.test is not o2.test
f();//aaa aaa
//with lexical this
o.m=function() {var self=this; var func=()=console.log(this.test+'
'+self);func()}
var f=o.m;
o2.m=o.m;
o.m();//bbb bbb
//this.test is o.test
//lexical |this| is associated to dynamic |this| outside func
//you don't need the var self=this statement
o2.m(); //ccc ccc
//same as above
f();//aaa aaa
//other example
o.m=()={console.log(this.test)};
var f=o.m;
o2.m=o.m;
o.m();//bbb
f(); //bbb
//should be aaa if no lexical this
o2.m(); //bbb
//should be ccc if no lexical this
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
strict mode |with| proposal
Draft is here : https://gist.github.com/edd064e5b29e67ebe493 Maybe everything is not accurate regarding some comments and annex should include other examples but, before writing more, let's submit it As mentionned in the gist, it is supposed to address several topics : security and wrapping, modules, multiple globals, VMs and proxies It did not come up just this morning, it can be called a |with| nothing proposal, |with| is not light in specs and rarely used, it was eliminated in strict mode (even if some non strict/strict mode combinations use it, see recent cajaVM analysis) but maybe strict mode can give it another meaning. The concept is simple and based on the implementation of VMs where if you have to pass something to |with| or other, then it's totally impossible to separate it completely from the initial scope (see annex) There is a disruptive assignment floating in the |with|'s code : this=window (which then sets the ThisBinding and associated var bindings), which has to follow some rules (must be in root, can not be invoked twice, etc), might look strange but it's a kind of LHS lexical |this|, so maybe no more disruptive than the lexical this At the end the result is simple and simple to use, does eliminate a lot of complications, is flexible (you can decide whether |with| stuff reminds isolated or not and vice-versa, clone global var or not, freeze stuff or not, etc), and probably light in terms of specs modifications/implementation. -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA-262 purview? was re: FFT module
I don't see how a FFI could really help developers. What would be needed is a not empty intersection between http://developer.apple.com/library/safari/navigation/, https://wiki.mozilla.org/WebAPI, WHAT WG, W3C, etc, unfortunately it is not the case at all Or something like phonegap if it can become a standard (out of TC39) The reality today is that it has became impossible to developp a web app supported by all platforms in a way that it looks like a native app (unless you get the fundings and appropriate team, or use something like phonegap, but what do you know about the future of phonegap ??). It requires too many efforts, my last projects are plenty of hack/hook (if ie, if webkit, if webkit ios, if bada, if blackberry, if ff, if webkit chrome, if, if, if...), and attempts to use build-in js or css features (animations, motion, ...) generally lead to very poor results (of course there are plenty of perfect examples showing that this works very well, but once the examples get modified to match reality, it never works correctly), on your way you can be blocked by some surprising implementation orientations (like bada deciding not to implement the synchronous xhr), then moving forward usually you have to decide to eliminate some platforms. At the end, finally, you can package your app for selected platforms and your are welcome to put it on hundred of stores, pay for it, wait for reviews, share revenues, maintain it, etc B. Eich is mentionning the good unification efforts in terms of specifications but some parties are missing and some regressions did happen too. Indeed, in all this process you might have decided to use some well known apis for your apps, and one day you might discover that the apis have been shut down or that you have to pay for it, or that you will have to pay for it, or that it will be shut down and replaced by something else less performant that you must pay too. This is not fair of course since the community did participate to build these apis and just get in return the fact that its apps will no longer work, this is exactly my case today for past projects and ongoing (now blocked) one. Nothing to do with the initial subject ? Yes, it does, the actual (web) world is (not) the best// of all// possible worlds and I don't think we can afford continuing having exploding number of platforms, systems with different behaviors and no unified specs (not talking about tc39 here) Maybe it's a dream or it's alreday too late Le 22/05/2012 11:40, Claus Reinke a écrit : Different native-code compilers and OSes (not always tied, btw) will choose different FFIs, depending on local macro- and micro-economics. Even today we have a choice between calling conventions on Windows (not always obvious; Rust has changed at least once in its young life). That is all within the purview of a standard FFI to address. For instance, the Haskell FFI has foreign import and export declarations that include calling conventions, and I've seen both ccall and stdcall in practice, depending on the native library and OS in question. Haskell 2010 Chapter 8 - Foreign Function Interface http://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008 Haskell code imports a Haskell library interface, it is up to the build phase of a library with foreign declarations to connect Haskell calls to native calls, sorting out the OS dependencies. Sometime around 1997, I worked on connecting Haskell and Java code via their languages' native interfaces, before they arrived at today's standard FFIs. I found that the differing implementations (bytecode compiler/interpreter, native compiler) had come up with roughly similar solutions to similar problems. The standardization processes merely removed accidental differences, and ironed out the kinks, based on practical experience. It also reduced the need for pre-processors that had been used to retarget a single Haskell code base to different implementation-specific FFI approaches. Most high-level languages seem to have some form of FFI (SML, Java, ..). The OS and compiler release schedules are decoupled from browser and other JS engine-bearing software cycles. That's the whole idea of a standard FFI: it allows to specify a stable interface, so that clients (here JS code running on JS engines) and providers (here their host platform environments) can evolve independently, without breaking code. FFIs are inherently unsafe if not crippled or lumbered with a complex research project such as NaCl or Xax. Safety is indeed a major FFI issue, and the dynamic and pervasive nature of JS environments makes it critical. However, we have a whole ecosystem of JS code that relies on webviews nested in native code, where the native code freely re-interprets webview actions to trigger arbitrary native actions and to feed back their results to the webview. JS FFIs already exist in practice. One point of a
Re: ECMA-262 purview? was re: FFT module
TC39 is obviously not the right place for FFI, but the subject can be discussed. I and my former team did develop (modestly) quite a lot of stuff as well that could be called FFI, result : 0 in the middle/long term Hopefully now the web gets some nice things like node.js at server side But at device level, it should be up to vendors to propose a unified, performant and cross browser js interface, personnaly I will not go any more into the nightmare I described in my previous email, and I think less and less people will It's a paradox, while the iphone brought light, shadow follows now with every vendor/platform thinking they can specify whatever they like, and others thinking they can shut down whatever they like (tip : the name starts by a G) Le 22/05/2012 19:17, Wes Garland a écrit : On 22 May 2012 12:54, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: I don't see how a FFI could really help developers. FFIs are certainly helpful in many situations. I don't think this is one of them. Let me relay a relevant xperience. We develop applications in Server-Side JavaScript. We have an FFI that, with some magic compile-time shims and a few other tricks, lets us write close-to-the-bare-metal applications that are portable without platform detection across many operating systems -- in fact, I believe, to any conformant SUSv3 implementation. We write nearly-C-like code on Linux, Solaris, and Mac OS X, 32 and 64 bit, to give us nice JS libraries on top of the ugly, bare metal. Our implementation is complete enough that we were able to write a complete WebSockets implementation in JS, that runs on many platforms, with no direct support in the host environment other than FFI, right down to the networking system calls, including the magic macros for select (FD_CLR et al). Sounds great, right? Well, it is for us, but it would make a lousy direction for a standard: the resultant JS is completely non-portable to Windows. Or QNX. Or Gronch. Or a myriad of other operating systems. And that's the real problem. We have overcome the typical C porting problems -- endianness, word size, whether fstat() is a function or a macro, etc. but we're still nowhere close to being portable to where the web needs to run. If we want to run anywhere, we would need to FFI up one layer of abstraction, to something like APR or NSPR, and then guess what? We would be no better off in any way than what the standards guys have been up to -- and far, far, worse off in many. That's why I believe TC-39 is not the right place for a JS FFI. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Remaining Hazards and Mitigating Patterns of Secure Mashups in ECMAScript 5
Finally I could hear the talk (++ too bad that the end is missing)
Then I took a look mainly at domado.js, startSES.js, repairES5.js
Quite clever, but quite complicate...
I did focus on cajaVM.eval and tried to theorically follow its process
with an example as described below, with some small simplifications
since security is one thing but the final result of VM processing
(whether security is involved or not) is interesting too
Maybe it will be undigest for other readers since it is difficult to
summarize if you do not have all the code, but again it's quite smart as
js allows (even if I have some doubts about performances with all the
getters and setters, and even with proxies being added later to help
this), I hope my understanding is correct, the exercise is not just a
vue de l'esprit, I have something in mind since some time related to
this and other things that I might submit, maybe to simplify a little bit.
function compileExpr(exprSrc, opt_sourcePosition) {
var wrapperSrc = securableWrapperSrc(exprSrc, opt_sourcePosition);
var wrapper = unsafeEval(wrapperSrc); //eval
var freeNames = atLeastFreeVarNames(exprSrc);
var result = makeCompiledExpr(wrapper, freeNames);
return freeze(result);
}
sharedImports : copy of the global object with original properties
frozen (parseInt, etc);
imports : clone of sharedImports; //this is now our virtual global
for code execution
//ex :
imports.parseInt -- parseInt
window : imports; //let's call it window for better understanding, see
it as a gadget's own window, not the usual global window
window.window=window; //Assign window property to window refering to
itself. I did not see it in the code but probably it is somewhere
window.d=d; //define it not frozen
window.f=f; //define it frozen
src='var a=a;window.b=b;c=c;parseInt=evil;d=D;f=F;this.g=g';
wrapperSrc='(function() {
with (this) {
return function() {
use strict;
return (
var
a=a;window.b=b;c=c;parseInt=evil;d=D;f=F;this.g=g;
);
};
}
})';
wrapper=function() {
with (this) {
return function() {
use strict;
return (
var
a=a;window.b=b;c=c;parseInt=evil;d=D;f=F;this.g=g;
);
};
}
}
freeNames=['a','c','parseInt','d','f'];
scopeObject= { //frozen
a: {get:scopedGet, set:scopedSet}, //set and get window.a
c: {get:scopedGet, set:scopedSet}, //set and get window.c
d: {get:scopedGet, set:scopedSet}, //set and get window.d
parseInt: window.parseInt, //initial parseInt, not evil
f: f
}
function() {
with (this) {
return function() {
use strict;
return (
var
a=a;window.b=b;c=c;parseInt=evil;d=D;f=F;this.g=g;
);
};
}
}.call(scopeObject)
returns :
function() {
use strict;
return (
var
a=a;window.b=b;c=c;parseInt=evil;d=D;f=F;this.g=g;
);
}
whose's scope is still under the |with| statement where :
a: {get:scopedGet, set:scopedSet}, //set and get window.a
c: {get:scopedGet, set:scopedSet}, //set and get window.c
d: {get:scopedGet, set:scopedSet}, //set and get window.d
parseInt: window.parseInt; //initial parseInt, not evil
f: f //frozen initial value
Then :
function() {
use strict;
return (
var
a=a;window.b=b;c=c;parseInt=evil;d=D;f=F;this.g=g;
);
}.call(window)
//|this| does refer to window for code execution
window.a===a; //scopedGet result
window.b===b; //assignment by window property of window
window.c===c; //scopedGet result
window.parseInt===parseInt; //parseInt reassignment fails (frozen),
scopedGet result
window.d===D; //scopedGet result
window.f===f; //frozen initial value
window.g===g; //|this| is window
Le 20/03/2012 06:27, Mark S. Miller a écrit :
On Mon, Mar 19, 2012 at 3:10 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
'Avoid “this”. Use closures rather than prototypes'
Probably the public was stunned by that one... (technical problems
too, could not hear the video, just saw the slides)
Not really. I expected more resistance than I got. During the 20
minutes of lively QA, this came up again. I clarified then something
I should have said earlier in the talk. The objects that need to be
defensive are those that might be exposed across a trust boundary,
such as the counter in the first example. For objects purely inside
one trust domain, given that we really are confident they cannot
escape, they do not need to be defensive since their clients are all
presumably intimately cooperative.
Technically for the purpose of your presentation, it is correct,
but I am coming back again to real life, you are using strict mode
and other means (such as questionnable setTimeout(xxx,0)) to
secure Bob.
Sorry
Re: TC39 bashing
Le 10/05/2012 20:04, Anton Kovalyov a écrit : it'd be really nice to have down-to-earth explanation of harmonized changes with code samples that resemble real world use cases. Yes. TC39 can not ask the opinion of every developers or community representatives, and developers can not spend their time following TC39 But I am not sure that TC39 does really realize how far they are from the advanced developers, not talking about the usual webmasters... A side effect is that a lot of wrong things are advised or said on well known forums or projects, then things keep being developed wrongly as it is the tendance since a long time in the web world, and right code is reserved to a very specific elite, making both life of language designers and developers hard, making js less and less accessible Then the truth should come from TC39 with the help of developers, and maybe a significant effort should be made to make things more understandable with simple real world use cases, starting with official strawman proposals/ES specs simplificated version annexes that could include for example this kind of attempt https://github.com/es5/es5.github.com/pull/14 A performances annex would be good too (ie what to use or not use if you care about performances) On Thursday, May 10, 2012 at 9:34 AM, Mikeal Rogers wrote: On May 10, 2012, at May 10, 20121:41 AM, David Bruant wrote: Le 10/05/2012 04:44, Mikeal Rogers a écrit : The core problem is that people who work nearly full time on designing a language are necessarily out of touch with people using it, and the people using it are ill equipped to balance the priorities all all the parties involved in designing it. I understand your point, but I'm afraid I disagree with your vision which I think is too simplistic. Dave Herman's task.js is a library that has been suggested on the JSFixed thread about asynchronisity [1]. Dave Herman is part of TC39 and what he did seems to resonate well in the developer community. It seems like you're opposing people who design the English language and people who use the English language. The world is not that dichotomic. People who used ECMAScript 3 felt the lack of .bind. People who design the language added it in ECMAScript 5. I think a better strategy is for TC-39 to state definitively what is *not* currently working on or is of a very low priority. This would allow the community of people using JavaScript to tackle those problems more directly rather than just waiting. At some point in the future TC-39 can adopt or ratify behavior that has proved itself in the community. I know this process is eluded to often but I don't think you understand how much momentum gets sucked out of the community when they are under the impression that new behavior will be handed down from TC-39 and that their work may fall in conflict or out of date. The recent discussion about Object.isObject is a great example. If this isn't happening please state so definitely so that we can rally around existing work (underscore) or build something new. This point is interesting. Among the changes that TC39 have to make to the language, I see 2 categories. One is adding new language capabilities (WeakMap, proxies, lexical |this| functions, binary types, proto operator, etc.) the other is new built-in functions (for Array, Math, Object, etc.). Maybe the latter category could be (partially) delegated to the developer community and ratified by TC39. I foresee that with modules, a new field for this second category is opening and there will have some important discussion about what module should be in the standard and which shouldn't. Maybe the responsibility for this part could be also shared with the developer community since they are those who usually write these functions (out of need). There is a difference to TC-39 but not much of a different to the community. The web developer motto is suck it up, if something is broken we write a workaround or monkey patch it, If something is impossible to do one way we find another way. People in the community don't ask for WeakMap until there is a proposal. Instead they come up with other crazy ways to accomplish their end goals without needing such a type to varying degrees success (we're still finding leaks in FreeList in node.js http.js that might have been prevented had we had WeakMap a few years ago). It might be beneficial to invite a few people from the developer community to meetings and to rotate them out so that no one becomes truly intrenched in the process. Or that the developer community decide to gather by itself and then share feedback on es-discuss. That's hard. JavaScript is a diverse community which also means that it is fragmented. I think the node.js community has a good core group of leadership with somewhat consistent ideas about what the community wants from the language. There are leaders in the web developer
Re: Bound instance-function vending (was RE: Arrow binding)
1- Yes, several time that you mention it, and ++ from me each time
2- I prefer the dot notation rather than Object.extend, even if both are
good
Le 28/04/2012 20:49, Kevin Smith a écrit :
Hi Angus!
1) Kevin et al suggested YAGN call/apply on (non-method)
functions. Here's a pretty neat example where call/apply is a
perfect fit for standalone functions - and would break if replaced
with fat arrows.
https://gist.github.com/2520731
This is a great example. Two points:
1.) In this case, I think it's going to be pretty difficult to prove
that a dynamic this arrow function would be any more readable or
better than current syntax:
// On what basis is this:
this.initialize = () - { ... };
// any better than this?
this.initialize = function() { ... };
There are a couple of characters saved, but it's less readable. Why
introduce new syntax for such dubious gain?
2.) For mixin stuff like your example, I think the elegant solution is
object literal extension syntax:
https://gist.github.com/2521128
I'm not sure of the status of that syntax, but hopefully it will get
included in ES6.
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Remaining Hazards and Mitigating Patterns of Secure Mashups in ECMAScript 5
Thanks for your answer, I am myself involved since some time in the DOM and gadgets/widgets's interaction topic. I will hear the presentation, right now I have a (stupid) problem of non working headphones. Bob and Alice are ok, but sometimes a good real example can help (last paragraph). setTimeout(xxx, 0 or 1 or 2 or 500) could be questionable because this is supposed to be fordidden (or not good code...), but surprisingly all major sites do use it, myself too (https://github.com/Ayms/node-dom), regarding http://dbaron.org/log/20100309-faster-timeouts : web workers or postmessage -- bof, I used both in the past for other purposes, prefer setTimeout here Then if I understand correctly a short summary could be that Caja does help for example iGoogle to move gadgets outside of iframes then they potentially could hurt things but Caja does prevent it and allow them to interact between each others safely (using ES5 improvements) OK but not everybody is coding safely like Google (even if iGoogle code is very surprising...), then it's difficult to estimate the overall benefit and usuability. It's the same issue as multiple globals (if the concept of globals still exist in the future) I believe : how to separate completely several contexts while using objects between each others ? Looks very difficult It's not exactly the same case in fact, except if each gadget becomes an entity with its global object derived from itself (but not an iframe) For proxies, I am not expert, what does it bring to emulate the dom faithfully ? Le 20/03/2012 06:27, Mark S. Miller a écrit : On Mon, Mar 19, 2012 at 3:10 PM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: 'Avoid “this”. Use closures rather than prototypes' Probably the public was stunned by that one... (technical problems too, could not hear the video, just saw the slides) Not really. I expected more resistance than I got. During the 20 minutes of lively QA, this came up again. I clarified then something I should have said earlier in the talk. The objects that need to be defensive are those that might be exposed across a trust boundary, such as the counter in the first example. For objects purely inside one trust domain, given that we really are confident they cannot escape, they do not need to be defensive since their clients are all presumably intimately cooperative. Technically for the purpose of your presentation, it is correct, but I am coming back again to real life, you are using strict mode and other means (such as questionnable setTimeout(xxx,0)) to secure Bob. Sorry, but we're using these techniques in real life. And what's questionable about setTimeout? (or better, http://dbaron.org/log/20100309-faster-timeouts) Then what is the use of Bob if he can not do anything outside of himself ? Please do make an effort to surmount whatever technical difficulties you encountered, so that you can listen to the audio of the presentation. The slides were not constructed to be self explanatory, and the talk was clear on this point. A much more trivial security leak could be that the calling context does somewhere unexpectedly (or not) something like counter.x.y.z=window (Ex : like passing a node to Bob since it seems that Bob has to do some stuff with the dom to be usefull) If Alice does not trust Bob, Alice should generally never give Bob direct unmediated access to one of her dom nodes. Instead, she gives him access to a virtual dom tree that wraps the real dom tree, allowing Bob to manipulate a subtree of Alice's dom tree. We constructed the Domado library http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/plugin/domado.js for exactly this purpose. The difficultly of emulating the dom faithfully in JS was also the original impetus for the proxy work. The Domado library above does not rely on proxies, as they are not yet as available as ES5. It's the same issue as multiple globals (if the concept of globals still exist in the future) I believe : how to separate completely several contexts while using objects between each others ? Looks very difficult I might be wrong, but on what today's examples the demonstration here could apply without Bob being useless or just returning something like a mathematical calculation or such not touching anything in the page ? I'm sorry, I didn't understand these last two paragraphs. Could you clarify? You might also want to try some of the scenarios you have in mind at https://caja.appspot.com/. -- Cheers, --MarkM -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es
Re: Remaining Hazards and Mitigating Patterns of Secure Mashups in ECMAScript 5
'Avoid this. Use closures rather than prototypes'
Probably the public was stunned by that one... (technical problems too,
could not hear the video, just saw the slides)
Technically for the purpose of your presentation, it is correct, but I
am coming back again to real life, you are using strict mode and other
means (such as questionnable setTimeout(xxx,0)) to secure Bob.
Then what is the use of Bob if he can not do anything outside of himself ?
A much more trivial security leak could be that the calling context does
somewhere unexpectedly (or not) something like counter.x.y.z=window (Ex
: like passing a node to Bob since it seems that Bob has to do some
stuff with the dom to be usefull)
It's the same issue as multiple globals (if the concept of globals still
exist in the future) I believe : how to separate completely several
contexts while using objects between each others ? Looks very difficult
I might be wrong, but on what today's examples the demonstration here
could apply without Bob being useless or just returning something like a
mathematical calculation or such not touching anything in the page ?
Le 18/03/2012 19:25, Mark S. Miller a écrit :
[+synodinos]
On Sun, Mar 18, 2012 at 5:27 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 18/03/2012 02:06, Mark S. Miller a écrit :
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5
Has some new material relevant to issue we discuss on this list.
Enjoy!
The end of the talk is missing, isn't it?
yes, The last comment from Dio (cc'ed) of InfoQ, the organization
putting on the conference, says:
21 hours ago
by *Dionysios Synodinos*
Due to a technical issue (tape corrupted) the last 20' of this
presentation where lost. Please accept my apologies on behalf of
the InfoQ team.
You can find the *_full_* presentation slides in PDF format here:
http://qconsf.com/dl/qcon-sanfran-2011/slides/MarkS.Miller_RemainingHazardsAndMitigatingPatternsOfSecureMashupsInEcmaScript5.pdf
I was very disappointed to find this out because the session went on
for another 20 minutes or so, with some really great audience
interaction. Oh well.
What are the 2 other attacks?
I'd try to guess:
1) Assuming Bob subscribes before Carol:
// in Bob
topic.subscribe(function republish(publication){
if(publication === pub)
topic.publish(other publication);
});
topic.publish(pub);
Since the call to publish is synchronous, Carol see the other
publication before pub while it should be the other way around
(according to Alice's intention regarding delivery order).
Very good. This is indeed the third attack shown on slide 48 of the
pdf linked to above.
This can
probably be solved with a publication queue or redefining publish as :
function publish(publication){
setTimeout(prevousPublish.bind(undefined, publication), 0);
}
Making the call occur in a later turn guarantees that it happens after
the current turn. Event loop takes care of run-to-completion and turn
ordering.
If Carol has all her subscribers before Bob's, I don't see how Bob can
attack on this front.
Very good again. This is the defense against the third attack, shown
on slide 50. (With the applyLater helper function defined on slide
49). It is shown again on slide 51 using the strawman infix ! sugar.
2) A DoS attack by adding subscribers within a subscriber
topic.subscribe(function resubscribe(publication){
topic.subscibe(resubscribe);
});
topic.publish('bla');
No, I consider this attack to be out of scope, as a DoS attack can be
trivially mounted anyway by any code in that frame which receives
control, simply by going into an infinite loop. (Regarding the browser
timeout-abort workaround for infinite loops, these only defend against
accidents. There are plenty of other ways for code within a frame to
successfully DoS that frame.)
[...]
3) There were only 2 attacks left and this is more ambiguous, but
assuming the publication is mutable, any subscriber can alter it.
A complicated defense is to copy the publication and pass a copy
to each
subscriber. An easier defense is to pass immutable publications.
In a WebIDL-conformant platform, this could be easily achieved by
removing all setters of all event-related properties (they are all as
accessor on *Event.prototype objects).
Have I found the 2 remaining attacks?
As Felix says, you already saw attack #1 at slide 45. Attack #2 is
Aborting the wrong plan on slide 47. The defense on slides 50 and 51
defends against both attacks #2 and #3. And the code on those slides
already incorporates the defense against attack #1.
And my concluding slide #52 was a callback to slide #3.
--
Cheers,
--MarkM
Re: BTF Measurements
Forget this below, sorry I got confused, coming back to your first email
your tool does count function expressions that do not have this in
their immediate scope, so indeed functions that potentially need the
literal this, then you add object literal methods, then this leaves
10% function that can keep the old syntax or get a new shorter syntax
that does not bind this
OK, then I have tried again the tool on an ajax app
(http://www.blimpme.com/mobile), the total BTF candidates drops to 77.6 %
I think it is due to the fact that :
var x=document.createElement('div');
x.onmousedown=function() {var a=this.style};
var y=function() {var a=this;};
x.onmouseover=y;
are not counted as BTF candidates
Since I have not yet understood what should become methods with the
arrow/do or do proposals, I can not say more...
Le 14/03/2012 22:15, Aymeric Vitte a écrit :
So BTF stands for bound-this function expressions
But it does include case b (don't care about this)
Then in the next email you conclude :
Interestingly, when we take the sum of BTF candidates and object
literal methods, we account for over 90% of function expressions.
Is it surprising ?
This suggests that an additional short function syntax that does
*not* bind 'this' may not be necessary.
??? Why because except object literal methods (+/-50% for which the
lexical this is not supposed to be needed) most of the functions are
the b case ?
I should be missing something important... don't understand exactly
what the analysis does highlight, thanks if you can explain
Le 14/03/2012 13:46, Kevin Smith a écrit :
As far as I have understood Total Function Expressions is
supposed to return all functions that do not contain this in
their initial scope and that have a var self=this trick that is
used somewhere inside the function (ie function() {var
self=this;var b=function() {console.log('test')} is not a BTF
candidate because self is not used), correct ?
Sorry, no. As stated previously, I'm assuming for the purposes of
this analysis that BTFs will be used in cases where (a) we want
lexical this and (b) we don't care about this at all. Why in the
second case? Because BTF syntax will be more concise and will
generally express the intent better.
When I started this research, I wasn't aware of the tri-lambda work
being done, and specifically the proposal that there be two short
function syntaxes: one for classic functions (-) and one for bound
this (=). Clearly some of the BTF candidates could go either way,
and we really can't make that distinction in this analysis.
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: BTF Measurements
Hi,
I think I have missed something in the discussions (or globally) because
I don't understand very well why methods are involved in lexical this.
But if it is so, why events handlers should be different from a js
perspective ? Maybe you could include in the tool everything that is a
method function expression
Probably it will be more clear once the proposals are updated (or maybe
I read it in a wrong way but I don't see what happens to methods), and
the example below illustrated (I have tried to write what it will
become, probably completely wrong) :
Today
var a=function() {var self=this;var c=function() {var a=self;return a}};
var test='essai';
var o={test: 'test'};
o.m = function() {var a=this.test;return a}
a = o.m;
var b=function() {};
b.prototype={
test2: function() {var a=this;return a}
}
o.m(); //test
a(); //essai
- Tomorrow
var a=function() {var c=() = this}; (fat arrow)
or
var a=fn() {var c=() = do {var a=this;return a}; (fn + fat arrow)
or
var a=fn() {var c= do () this}; (do)
or
var a=fn() {var c= do () {var a=this;return a}}; (do)
b.prototype={
test2: () = this
}
or
... same as above
or
b.prototype={
test2() {var a=this;return this}
}
o.m = () = this;
or
o.m =() = do {var a=this.test;return a};
or
o.m = do () this;
or
o.m = do () {var a=this.test;return a};
a=o.m;
o.m();//essai ???
a();//essai ???
Le 16/03/2012 14:44, Kevin Smith a écrit :
Hi Aymeric,
I'm glad we're on the same page. I analyzed the code from that site
and got the same results as you. The percentage of BTF candidates is
68% of all function expressions, but the combined BTF candidates and
object literal methods are only 78%.
There are very few object literal methods in this sample, so in order
to explain the 78% we're going to have to dig into the non-method forms.
As you point out, event handlers are attached using the following idiom:
element.onevent = function() { ...this... };
Although they are not trivially convertible to BTFs, event handlers as
above can generally be refactored like this (using a purely expository
BTF syntax):
element.onevent = () = { ...element... };
or even:
element.onevent = (evt) = { ...evt.target... };
I think think analysis supports the idea that BTFs are widely applicable.
kevin
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Class declarations
The first question maybe in all these discussions is what is needed or
not (in real life).
In BTF discussions I gave an example where (surprisingly) for an app
there were a very few prototype like declarations.
Because I just did not need it for this app.
The second question is maybe whether ES is designed for frameworks or
apps, I will go for the second one, apps do not necessarly need
frameworks, libraries, etc, and frameworks do help developers not to
understand what they are doing
Then adding classes or such looks to complicate more things while
existing prototype behavior is good
Maybe the focus should be put more on performances
Le 17/03/2012 00:22, Brendan Eich a écrit :
Mark S. Miller wrote:
I agree with Waldemar. Classes aside, since code like
{
//...foo...
let x = 3;
function foo() { return x; }
//...
}
is statically legal, and is only wrong if foo is called before x is
initialized, the dynamic dead zone is very valuable. Otherwise, the
call to foo() silently proceeds with a meaningless result.
If you'd really rather have silent meaninglessness, use var instead
of let.
Classes are sugar for objects with properties, though -- rememeber, we
agreed to sugar the protoypal pattern, not the closure pattern.
A declared variable binding is different from an object property. They
aren't the same thing.
And properties can be used before initialization in JS today (and in
Dart -- you Google guys are not all following the same rules :-P).
It seems to me you're not agreeing or disagreeing with anything about
classes as prototypal sugar, rather you're trying to reason about
properties by pointing to let binding rules. Last July I flagged
classes as subject to conflict and confusion in TC39 due to this
declaration vs. property conflation. If we can't agree to avoid it by
letting properties by properties, then classes are indeed out for
ES6 -- and out of Harmony for now.
/be
On Fri, Mar 16, 2012 at 3:50 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Brendan Eich wrote:
We can defer these by deferring guards and const instance
properties, and tried to do so. But IIRC at least Waldemar was
not happy leaving writable instance properties usable (with
default value undefined) before being initialized.
Of course, Dart allows this and discloses null on use before
initialization:
class Foo {
var a;
Foo(a) {
print(this.a);
this.a = a;
}
}
main() {
var foo = new Foo(42);
print('main: ' + foo.a);
}
Tested at http://dartlang.org/.
/be
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
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
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: BTF Measurements
I have tried the tool with node-dom (https://github.com/Ayms/node-dom)
to check what it would give on a whole site, not only a framework, see
the result below for a usual web site (here http://www.castorama.fr), I
did not compile it yet because it seems that there is a slight problem
with the tool :
(function() {}) or (function(){var a=2}) etc ...
returns a BTF candidate...
I discovered it checking
http://www.castorama.fr/homepage/homepage_20120227_full_anim.js which
returns 21 BTF (because I was surprised by the result, since these sites
are using frameworks we should not expect a lot of BTF functions outside)
As far as I have understood Total Function Expressions is supposed to
return all functions that do not contain this in their initial scope
and that have a var self=this trick that is used somewhere inside the
function (ie function() {var self=this;var b=function()
{console.log('test')} is not a BTF candidate because self is not used),
correct ?
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script http://www.castorama.fr/store/js/jquery.js
Total Function Expressions*:417 52.85% of 789
Expression Functions**:132 31.65%
Expression Functions That Return an Object Literal:2 0.48%
Functions with a single statement: 95 22.78%
Block Functions:190 45.56%
-- script http://www.castorama.fr/store/js/main.js
Total Function Expressions*:49 72.06% of 68
Expression Functions**:1 2.04%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 26 53.06%
Block Functions:22 44.90%
-- script inline
Total Function Expressions*:4 100.00% of 4
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 3 75.00%
Block Functions:1 25.00%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script http://www.castorama.fr/store/js/jquery.js
Total Function Expressions*:417 52.85% of 789
Expression Functions**:132 31.65%
Expression Functions That Return an Object Literal:2 0.48%
Functions with a single statement: 95 22.78%
Block Functions:190 45.56%
-- script
http://www.castorama.fr/homepage/homepage_20120227_full_anim.js
Total Function Expressions*:21 100.00% of 21
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 17 80.95%
Block Functions:4 19.05%
-- script
http://www.castorama.fr/homepage/homepage_20120227_full_menu.js
Total Function Expressions*:1 50.00% of 2
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 1 100.00%
Block Functions:0 0.00%
-- script http://www.castorama.fr/js/jquery.cookie.js
Total Function Expressions*:1 100.00% of 1
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 1 100.00%
Block Functions:0 0.00%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script http://www.castorama.fr/js/s_code.js
Total Function Expressions*:6 60.00% of 10
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 2 33.33%
Block Functions:4 66.67%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script inline
Total Function Expressions*:0 0.00% of 0
Expression Functions**:0 0.00%
Expression Functions That Return an Object Literal:0 0.00%
Functions with a single statement: 0 0.00%
Block Functions:0 0.00%
-- script http://www.castorama.fr/js/tc_Castoramafr_1_load.js
Total Function
Re: BTF Measurements
So BTF stands for bound-this function expressions
But it does include case b (don't care about this)
Then in the next email you conclude :
Interestingly, when we take the sum of BTF candidates and object
literal methods, we account for over 90% of function expressions.
Is it surprising ?
This suggests that an additional short function syntax that does
*not* bind 'this' may not be necessary.
??? Why ? Because except object literal methods (+/-50% for which the
lexical this is not supposed to be needed) most of the functions are the
b case ?
I should be missing something important... don't understand exactly what
the analysis does highlight, thanks if you can give more details
Le 14/03/2012 13:46, Kevin Smith a écrit :
As far as I have understood Total Function Expressions is
supposed to return all functions that do not contain this in
their initial scope and that have a var self=this trick that is
used somewhere inside the function (ie function() {var
self=this;var b=function() {console.log('test')} is not a BTF
candidate because self is not used), correct ?
Sorry, no. As stated previously, I'm assuming for the purposes of
this analysis that BTFs will be used in cases where (a) we want
lexical this and (b) we don't care about this at all. Why in the
second case? Because BTF syntax will be more concise and will
generally express the intent better.
When I started this research, I wasn't aware of the tri-lambda work
being done, and specifically the proposal that there be two short
function syntaxes: one for classic functions (-) and one for bound
this (=). Clearly some of the BTF candidates could go either way,
and we really can't make that distinction in this analysis.
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: BTF Measurements
For me no. I have looked into popcorn.js today and could not convince
myself that it was more readable, maybe it's a question of history or
feelings (and to get used to it) but without being an expert in all
languages, I consider js to be a unique (clever) language, using the
arrow notation makes it look like others, this argument might look weak
but for js or others I am not a fan of the arrow notation... will not
make friends, I know
It is confusing right now whether the arrow proposal and do proposal are
distinct/exclusive or not
I read about popcorn (-- Herby) :
error: ( msg ) - {
throw new Error( msg );
}
which should be
error (msg) {
throw new Error( msg );
}
Where is this specified ? And what happens with get: function() {.}
or set ?
Le 14/03/2012 21:53, Allen Wirfs-Brock a écrit :
On Mar 13, 2012, at 6:20 PM, Rick Waldron wrote:
Kevin,
Over the weekend I applied David Herman's new tri-lambda syntax to
Popcorn.js to see how it would look and feel:
https://github.com/rwldrn/popcorn-js/compare/tri-lambda
...
So when I scan the diffs and my eye pass over pairs of changes like:
-(function(global, document) {
+((global, document) - {
or
- var DOMContentLoaded = function() {
+ let DOMContentLoaded = () - {
or
-Popcorn.p[ api ] = function() {
+Popcorn.p[ api ] = () - {
or
-script.addEventListener( load, function() {
+script.addEventListener( load, () - {
my eyes invariably go to the first line of each pair and I have a
minor mental WTF moment when I look at the second line. Now some of
this is no doubt a matter of familiarity, but does anyone really think
that the second forms are more readable even with experience. At
least in western cultures, are brains are trained from a early age to
recognize meaning in words. Symbols are far less common and symbol
semantically meaningful symbol sequences are even rarer.
In what way does this syntax help people read and understand code?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Callable values: trying to summarize
I was not aware of this document when I wrote :
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021050.html
Reading my post again, it's indeed not clear at all that I was
referring more to the syntax than block lamdas's principles and that
this should behave as block lambdas, I got this answer :
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021055.html
Then I thought that the do proposals were definitely over, but
it's not the case and I have too a preference for it.
So, taking my examples 1 and 3 (what is the baseValue property in
your document ? Similar to my GetBase ??), how could we do that ? (or
please someone, just crash the idea once for all so I don't think about
it any longer)
The fn carrot for strict mode looks to be a good idea.
Le 12/03/2012 04:48, Allen Wirfs-Brock a écrit :
see https://gist.github.com/2015544 for my current thougthts
Allen
On Mar 11, 2012, at 11:20 AM, Axel Rauschmayer wrote:
== Arrow syntax ==
The nicest proposal I have seen has been written by David Herman:
https://gist.github.com/2011902
== More traditional solution ==
1. Short notation for non-TCP functions: use fn; enables one to abbreviate function as
fn [1]. Optional, not sure if that’s a good idea: Implicit return of completion value
and lexical `this`.
For example:
use fn;
arr.map(fn (x) { x * x });
2. Block lambdas for TCP-adhering callable blocks with lexical `this`, which
previously seemed like the main contender. As a TCP-adhering syntactic
alternative to block lambdas, Allen mentioned the following on Twitter:
do (args) { ... }
Open question: fn and function behaving differently seems like a bad idea,
because then things are less consistent. But then you have to wonder if fn is
really worth the trouble for only saving 6 characters.
[1] https://twitter.com/awbjs/status/178792012215091200
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
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
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional function keyword
Then you really have three somewhat modest proposals:
1. optional function.
2. braceless functions that auto-return the completion value of the
expression and exhibit TCP freakdeekness.
3. do-expressions blocks that evaluate to their completion value.
These three seem to combine to let you do all the good things that
block lambdas offer, and are pretty elegant and easy enough to explain
to new users, IMHO. The do token sort of looks like it means Do
this right here, not in a separate context.
Indeed it looks more intuitive than block lambdas (IMHO).
A variant/extension of () do {...} could be do {...} that (if not
followed by a while) will create Function() {...} that gets evaluated
when retrieveing a property ([[Get]]) or when called directly, allowing
new possibilities for this not all feasible with block lambdas or =
, not impacting a lot current specs, easy to understand and use,
examples :
*1- this.x in prototype*
var f=(name) {
this.name=name;
};
f.prototype={
nodeName : do {return this.name}; //creates an object =
Function() {return this.name} with a flag reminding that it was a do
creation
};
var g=new f('test');
//g.prototype={
//nodeName : do {return this.name};
//};
console.log(g.nodeName); //'test'
//[[Get]] returns a function=Function() {return this.name}, if the
do flag is true [[Get]] does evaluate it as if g.nodeName was called
(g.nodeName() -- function.[[Call]](g))
//this is evaluated to this.name, where this does refer to g
*2- closures*
//old way
var a={name : 'test'};
var f=function () {
var self=this;
(function() {console.log(self.name) })();
};
f.call(a) -- 'test'
//new way
var a={name : 'test'};
var f=() {
(do {console.log(this.name)})();
};
f.call(a) -- 'test'
//old way
function writeNodes() {
var self = this
var writeall = function() {
for (var n in self.nodes) {
self.write(n);
}
}
writeall();
}
//new way
writeNodes() {
var writeall = () do {
for (var n in this.nodes) {
this.write(n);
}
};
writeall();
}
*3- json*
var x={
a: 10,
b: do {this.a},
c: {
d: do {return GetBase(this)}
}
};
console.log(x.b);
//[[Get]] returns Function() {return this.a} and evaluate it (see
above)
//it is evaluated to this.a where this does refer to x
//returns 10
console.log(x.c.d);
//[[Get]] returns Function() {return GetBase(this)} and evaluates
it (see above)
//it is evaluated to GetBase(this) where this does refer to x.c
//returns x
var x={
a: do (this.b),
b: do {this.a}
};
console.log(x.b); //infinite loop...
*4- lexical this (??)*
var test = 'aaa';
var o = {test:'bbb'};
o.m = do {return this.test};
var f=o.m;
o.m(); //bbb
f(); //aaa
No improvement here, but if I am correct the improvement with block
lambdas is not obvious too :
var test = 'aaa';
var o = {test:'bbb'};
o.m = {|| return this.test};
var f=o.m;
o.m(); //aaa
f(); //aaa
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional function keyword
I forgot to mention that the call to () do {...} should work as written
in 11.1.7 in block_lambda_revival (if not my second example does not
work), so the behavior is supposed to be the same (if
[[FormalParameters]] is empty), I was more focused on the this stuff
(do examples 1 and 3 look useless ?).
I did not say that block lambdas were not interesting and powerfull, I
just think that this might be difficult to swallow/use by developpers,
so an intermediate approach maybe was not bad, but apparently it is no
possible.
Le 08/03/2012 19:22, Brendan Eich a écrit :
Aymeric Vitte wrote:
Indeed it looks more intuitive than block lambdas (IMHO).
Intuitions vary, but why does
function huh(a, b) {
let toss = () do{return a*b};
downward(toss);
return 42;
}
where downward, if it calls its argument, forces a return of a*b from
huh, and control never reaches the return 42, seem intuitive to you?
Does the () do ... syntax by itself convey a Tennent sequel?
Block-lambdas have precedent, intuitive or not, going back to
Smalltalk via Ruby, of behaving in this different and (to some)
surprising way. They look odd enough to better call attention to the
novelty, in my opinion, than a mix of () and do.
function huh(a, b) {
let lambda = {|| return a*b};
downward(toss);
return 42;
}
Anyway, the current proposal has grammatical issues already plaguing
arrow function syntax. Block-lambdas have no such problems. But this
is not a contest: we could have shorter function syntax (e.g., 'fn' if
not some prefix-less proposal that solves the grammar problems). And
we could have block-lambdas on top.
What we won't have is full TCP in a function-body-plan. Sufficiently
distinct semantics need markedly different syntax. Is '()do'
freaky-deaky enough? I don't think so, right now.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined in specs
to access properties of objects but nothing the other way, because I
believe the case never happens today.
The this proposal is not bad for me (and even good), if I take Lasse
Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b; this.b = this.a}; var
g = new f();//g.a undefined //g.b undefined
It does not solve your issue but it makes me think to a more global
issue, the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or this post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html
(which apparently did not passionate)
But this should not be applicable to functions only, this could be
generalized to objects, where this unless explicitely bound to
something should refer to the object itself, and not the global object
(moreover that there are discussions about the future of the global object)
Then an Object.GetBase could be added to refer to the parent or outer
object
I am not aware of all discussions (maybe it was already discussed and
rejected) and it's not easy to see the whole impact of such change, but
I don't think that the idea is absurd, I did not invent it myself and it
would be more logical than the current behavior of this and avoid
repetitives operations (var self=this, getters/setters, use of new (why
do I have to use new in the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, ??? a écrit :
{
a:123,
b: this.a
}
If you simply want this in JSON.parse, it will not be hard to
implement it in my library.
But I guess the problem is we have no way to refer to its parent. Do
you have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com mailto:gazhe...@gmail.com
It's a shame that this doesn't work with object literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org mailto: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
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Some object could have more than one ancestor.
Yes, so ? It's not in contradiction with what I am saying
Le 06/03/2012 14:58, 程劭非 a écrit :
I prefer this to be root object. Some object could have more than
one ancestor.
2012/3/6 Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined in
specs to access properties of objects but nothing the other way,
because I believe the case never happens today.
The this proposal is not bad for me (and even good), if I take
Lasse Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b; this.b =
this.a}; var g = new f();//g.a undefined //g.b undefined
It does not solve your issue but it makes me think to a more
global issue, the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or this post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html
(which apparently did not passionate)
But this should not be applicable to functions only, this could be
generalized to objects, where this unless explicitely bound to
something should refer to the object itself, and not the global
object (moreover that there are discussions about the future of
the global object)
Then an Object.GetBase could be added to refer to the parent or
outer object
I am not aware of all discussions (maybe it was already discussed
and rejected) and it's not easy to see the whole impact of such
change, but I don't think that the idea is absurd, I did not
invent it myself and it would be more logical than the current
behavior of this and avoid repetitives operations (var
self=this, getters/setters, use of new (why do I have to use new
in the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, 程劭非 a écrit :
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard to
implement it in my library.
But I guess the problem is we have no way to refer to its parent.
Do you have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com mailto:gazhe...@gmail.com
It's a shame that this doesn't work with object literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr mailto:avi...@jcore.fr
Web :www.jcore.fr http://www.jcore.fr
Webble : www.webble.it http://www.webble.it
Extract Widget Mobile : www.extractwidget.com
http://www.extractwidget.com
BlimpMe! : www.blimpme.com http://www.blimpme.com
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Even if GetBase was existing I don't know if it would cover all your
needs but unless I missed something I don't get your last example (where
p is defined and where GetBase is supposed to be called ?)
Le 06/03/2012 16:33, 程劭非 a écrit :
Sorry.
I mean the following case:
var x = {
a:{
},
b:{
}
}
x.a.p = x.b.p = {};
So GetBase is not able to decide to return x.a or x.b.
在 2012年3月6日 下午11:08，Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com写 道：
Some object could have more than one ancestor.
Yes, so ? It's not in contradiction with what I am saying
Le 06/03/2012 14:58, 程劭非 a écrit :
I prefer this to be root object. Some object could have more
than one ancestor.
2012/3/6 Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined
in specs to access properties of objects but nothing the
other way, because I believe the case never happens today.
The this proposal is not bad for me (and even good), if I
take Lasse Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b; this.b =
this.a}; var g = new f();//g.a undefined //g.b undefined
It does not solve your issue but it makes me think to a more
global issue, the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or this
post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html
(which apparently did not passionate)
But this should not be applicable to functions only, this
could be generalized to objects, where this unless
explicitely bound to something should refer to the object
itself, and not the global object (moreover that there are
discussions about the future of the global object)
Then an Object.GetBase could be added to refer to the
parent or outer object
I am not aware of all discussions (maybe it was already
discussed and rejected) and it's not easy to see the whole
impact of such change, but I don't think that the idea is
absurd, I did not invent it myself and it would be more
logical than the current behavior of this and avoid
repetitives operations (var self=this, getters/setters, use
of new (why do I have to use new in the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, 程劭非 a écrit :
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be hard
to implement it in my library.
But I guess the problem is we have no way to refer to its
parent. Do you have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com
mailto:gazhe...@gmail.com
It's a shame that this doesn't work with object
literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr mailto:avi...@jcore.fr
Web :www.jcore.fr http://www.jcore.fr
Webble : www.webble.it http://www.webble.it
Extract Widget Mobile : www.extractwidget.com
http://www.extractwidget.com
BlimpMe! : www.blimpme.com http://www.blimpme.com
--
jCore
Email : avi...@jcore.fr mailto:avi...@jcore.fr
Web :www.jcore.fr http://www.jcore.fr
Webble : www.webble.it http://www.webble.it
Extract Widget Mobile : www.extractwidget.com
http://www.extractwidget.com
BlimpMe! : www.blimpme.com http://www.blimpme.com
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
That will work everywhere, as I mentionned the issue is more global,
your case made me think about it, it's only the begining of a
suggestion, whether it's nice or not in the representation can be fixed
later, what I am questionning here is the abnormal/not optimized
behavior of this, still thinking about it, what I wrote below does not
solve all cases
Le 06/03/2012 17:33, 程劭非 a écrit :
That will work in json but Object.GetBase is not so nice.
Also I think GetBase(GetBase(GetBase(this))) looks a bit ugly.
在 2012年3月7日 上午12:22，Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com写 道：
Even if GetBase was existing I don't know if it would cover all
your needs but unless I missed something I don't get your last
example (where p is defined and where GetBase is supposed to be
called ?)
Le 06/03/2012 16:33, 程劭非 a écrit :
Sorry.
I mean the following case:
var x = {
a:{
},
b:{
}
}
x.a.p = x.b.p = {};
So GetBase is not able to decide to return x.a or x.b.
在 2012年3月6日 下午11:08，Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com写 道：
Some object could have more than one ancestor.
Yes, so ? It's not in contradiction with what I am saying
Le 06/03/2012 14:58, 程劭非 a écrit :
I prefer this to be root object. Some object could have
more than one ancestor.
2012/3/6 Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things
defined in specs to access properties of objects but
nothing the other way, because I believe the case never
happens today.
The this proposal is not bad for me (and even good),
if I take Lasse Reichstein's objection, I would say :
{a : this.b, //undefined
b : this.a } //undefined
Same as if you do : function f() {this.a = this.b;
this.b = this.a}; var g = new f();//g.a undefined //g.b
undefined
It does not solve your issue but it makes me think to a
more global issue, the lexical this here
http://brendaneich.com/2011/01/harmony-of-my-dreams/ or
this post
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020749.html
(which apparently did not passionate)
But this should not be applicable to functions only,
this could be generalized to objects, where this
unless explicitely bound to something should refer to
the object itself, and not the global object (moreover
that there are discussions about the future of the
global object)
Then an Object.GetBase could be added to refer to the
parent or outer object
I am not aware of all discussions (maybe it was already
discussed and rejected) and it's not easy to see the
whole impact of such change, but I don't think that the
idea is absurd, I did not invent it myself and it would
be more logical than the current behavior of this and
avoid repetitives operations (var self=this,
getters/setters, use of new (why do I have to use new in
the example above ?))
Regards
A. Vitte
Le 05/03/2012 13:16, 程劭非 a écrit :
{
a:123,
b: this.a
}
If you simply want “this” in JSON.parse, it will not be
hard to implement it in my library.
But I guess the problem is we have no way to refer to
its parent. Do you have any ideas?
2012/3/5 gaz Heyes gazhe...@gmail.com
mailto:gazhe...@gmail.com
It's a shame that this doesn't work with object
literals :(
How nice would this be:
{
a:123,
b: this.a
}
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr mailto:avi...@jcore.fr
Web :www.jcore.fr http://www.jcore.fr
Webble : www.webble.it http
Re: xxx : this.yyy in prototype
Declaring something like a:this.b in prototype is of no use (because in
all cases it will be equivalent at the end to declare something like a:c
where c=(this bounded object).b).
Intuitively, if we forget the specs and current behaviour, we could
think that doing such, this could have a chance to refer to the new
created object after the new statement, but of course it is not the case.
Instead we have to define getters and setters as mentionned below.
This can be compared to the var that/self=this trick in terms of
repeatability.
Something that is useless could be transformed to something usefull, but
right now I don't see a simple way to do it that creates more benefit
than harm.
Regards
A. Vitte
Le 15/02/2012 19:21, Aymeric Vitte a écrit :
I did not find any related subject in discussions or specs so here it
is :
var f=function(name) {
this._name=name;
};
f.prototype={
get nodeName() {return this._name},
get tagName() {return this._name},
get anotherNameInvention() {return this._name},
...
set nodeName() {},
set tagName() {},
set anotherNameInvention() {},
...
};
So in that case we have to define several getters and setters for
something that is refering to the same object, slowing down the
overall script execution, it would probably be better to have
something like :
f.prototype={
nodeName operator this._name,
tagName operator this._name,
anotherNameInvention operator this._name
...
}
var g=new f('test') -- g.nodeName is equal to g._name
While calling new the operator would indicate that g.nodeName must
be equal to g._name whether _name is a property or a method.
nodeName, tagName, etc could be defined in f but this does not solve
the case if we want them to be inherited properties.
Maybe no operator is required and the default behavior should be the
one described above (what could be the use of declaring something like
xxx : this.yyy in prototype ??? I have never seen it).
Example of use : js w3c dom implementation where objects own a lot of
redundant properties.
Regards
A. Vitte
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
xxx : this.yyy in prototype
I did not find any related subject in discussions or specs so here it is :
var f=function(name) {
this._name=name;
};
f.prototype={
get nodeName() {return this._name},
get tagName() {return this._name},
get anotherNameInvention() {return this._name},
...
set nodeName() {},
set tagName() {},
set anotherNameInvention() {},
...
};
So in that case we have to define several getters and setters for
something that is refering to the same object, slowing down the overall
script execution, it would probably be better to have something like :
f.prototype={
nodeName operator this._name,
tagName operator this._name,
anotherNameInvention operator this._name
...
}
var g=new f('test') -- g.nodeName is equal to g._name
While calling new the operator would indicate that g.nodeName must be
equal to g._name whether _name is a property or a method.
nodeName, tagName, etc could be defined in f but this does not solve the
case if we want them to be inherited properties.
Maybe no operator is required and the default behavior should be the
one described above (what could be the use of declaring something like
xxx : this.yyy in prototype ??? I have never seen it).
Example of use : js w3c dom implementation where objects own a lot of
redundant properties.
Regards
A. Vitte
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
