2日間ホントありがとう。 旅行から帰って疲れてるのにごめんね。 ホントごめん。 ホントに助かりました。 今度お詫びになんかするよ笑 ホントありがとう。 愛の偉大さがわかったわ笑 明日から仕事がんばってね 2012/09/29 14:30 <[email protected]>:
> Send es-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: ES6 spec: [[Home]] and HomeObject versus [[MethodName]] > and MethodName (Allen Wirfs-Brock) > 2. Re: Early error vs. error on first call to function vs. > runtime error (Domenic Denicola) > 3. Re: Early error vs. error on first call to function vs. > runtime error (Claus Reinke) > 4. Re: Feed back and proposal for modules: allow importing ES5 > files (???) > > > ---------- 転送メッセージ ---------- > From: Allen Wirfs-Brock <[email protected]> > To: Axel Rauschmayer <[email protected]> > Cc: es-discuss <[email protected]> > Date: Fri, 28 Sep 2012 13:35:54 -0700 > Subject: Re: ES6 spec: [[Home]] and HomeObject versus [[MethodName]] and > MethodName > feel free to file a bug > > On Sep 28, 2012, at 1:07 PM, Axel Rauschmayer wrote: > > In method environment records, you have HomeObject and MethodName, whereas > function objects have the properties [[Home]] and [[MethodName]]. This is > really just a minor nitpick, but it might make sense to rename [[Home]] to > [[HomeObject]]. > > Axel > > -- > Dr. Axel Rauschmayer > [email protected] > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > ---------- 転送メッセージ ---------- > From: Domenic Denicola <[email protected]> > To: Brendan Eich <[email protected]> > Cc: es-discuss <[email protected]> > Date: Fri, 28 Sep 2012 21:31:47 +0000 > Subject: Re: Early error vs. error on first call to function vs. runtime > error > On Sep 28, 2012, at 20:58, "Brendan Eich" <[email protected]> wrote: > > > John Lenz wrote: > >> The best thing I see for the future is if the Browser vendors didn't > reparse JavaScript when loading from cache, this would help the best case > scenarios, but doesn't help the worse case where it harder to find wins. > > > > Yes, why hasn't this happened? We had a Mozilla intern working on it, > but I'm not sure where that went. It seems no major browser caches > post-parsed tree serializations or other intermediate forms. Anyone know > differently? > > > > /be > > A pretty niche example, but: Windows 8 Store apps written in HTML5/JS are > “bytecode cached” at package time, i.e. downloading an app from the store > gives you bytecode instead of (or, in addition to?) pure JS. > > Details at > http://msdn.microsoft.com/en-us/library/windows/apps/hh849088.aspx > > > > ---------- 転送メッセージ ---------- > From: "Claus Reinke" <[email protected]> > To: "Brendan Eich" <[email protected]>, "Allen Wirfs-Brock" < > [email protected]> > Cc: es-discuss <[email protected]> > Date: Sat, 29 Sep 2012 00:31:58 +0200 > Subject: Re: Early error vs. error on first call to function vs. runtime > error > >> * Error on first call to a function, where the function contains what >> would be an early error but for the supposed cost of early error analysis. >> > > As I understand it, this goes back to "lazy parsing" > > http://ariya.ofilabs.com/2012/**07/lazy-parsing-in-javascript-** > engines.html<http://ariya.ofilabs.com/2012/07/lazy-parsing-in-javascript-engines.html> > > which, in turn, seems to want to support the found-in-practice > pattern of pre-loading not-yet-parsed code (eg, Google's code > in comments trick). > > https://developers.google.com/**speed/docs/best-practices/**mobile<https://developers.google.com/speed/docs/best-practices/mobile> > http://googlecode.blogspot.de/**2009/09/gmail-for-mobile-** > html5-series-reducing.html<http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html> > > The reason why that pays off is that sites tend to include > lots of code that they usually do not use, or for which they > don't know beforehand whether it will be used. In some cases, > the balance seems to be between utilization of HTTP requests > versus parsing of JS code. > > So there are use cases (though some of them are addressed by > newer element attributes), but there should be other, more direct, > ways to achieve the goal: > > - coders don't include code that isn't used (doesn't seem to work, but > is still worth mentioning) > > - the language or its environment include explicit means for including > code for possible (but not certain) use (similar to <script defer>, one > might consider a <script provide> with parse-on-use semantics?) > > In particular, I would like to know whether the bandwidth vs > parsing balance is the only motivation for lazy parsing. If yes, > then it is a web-specific issue, and the solution should not > affect server-side JS. > > Because there is a hidden assumption behind the lazy parsing > idea, namely: the parsing -when it is triggered- *will not fail*. > > If the parse correctness wasn't tested before serving the code, > there is no easy way of catching parse failure later. So there > would need to be a development mode and a serve mode? > > If you give me a switch/pragma to force early parsing/checking, > then I will use it in my code (another job for "use strict"?). And > if you give us a way to provide code for parse-on-use, someone > on the web will find that useful. But without such switch, I don't want my > JS engine to do its few "early" checks later, perhaps, just > to address real use cases badly and implicitly. > > Claus > > > > > ---------- 転送メッセージ ---------- > From: 程劭非 <[email protected]> > To: Russell Leggett <[email protected]> > Cc: es-discuss Steen <[email protected]> > Date: Sat, 29 Sep 2012 13:30:15 +0800 > Subject: Re: Feed back and proposal for modules: allow importing ES5 files > Import is currently used by Module. This way of using "import" looks like > a loader feature. > > 2012/9/26 Russell Leggett <[email protected]> > >> On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 <[email protected]> wrote: >> >>> Thanks, Claus and Alex, >>> >>> I've looked at the Loader but it seems to be async? >>> >>> I know there are many ways to load multiple files together(iframe, XHR, >>> script element and datauri for browser host) but what I'm suggesting is to >>> make es6 module more friendly to es5 libraries. >>> >>> I mean currently the es6 module grammar is using >>> >>> export var a; >>> var b; >>> var c; >>> >>> But why not export all top-level scope variables and let developers use >>> IFFE to hide variables? >>> >>> var a; // export a automatically >>> void function(){ >>> var b; >>> var c; >>> }(); >>> >>> This will make libraries like old versions of jQuery work with es6 >>> module without any code change. These libraries might be on CDN and >>> changing their code will be a big cost in some scenarios. >>> >>> >> Why not simply the proposal a little. It would be nice to be able to >> export top level etc. but I think there is a clear danger there. What if >> instead of trying to make arbitrary scripts into modules, we just did the >> loading, making sure the script was loaded before running the code that >> depended on it. ES5 relies on global scope, and so would this. Instead of >> allowing: >> >> import "jQuery1.3.2.js","MyModule.js" as MyModule; >> >> Maybe just allow something like: >> >> import "jQuery1.3.2.js" >> import "MyModule.js" >> >> $(......).attr(......) >> >> Those scripts would still be executed in the global scope, and so this >> module would be able to access $. It would be extremely easy to wrap this >> way as well. Otherwise, you'd still need to worry about actually loading >> the dependency, no? >> >> - Russ >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
