2日間ホントありがとう。
旅行から帰って疲れてるのにごめんね。
ホントごめん。
ホントに助かりました。
今度お詫びになんかするよ笑
ホントありがとう。
愛の偉大さがわかったわ笑
明日から仕事がんばってね
2012/09/29 14:30 <es-discuss-request at mozilla.org>:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> 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
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> 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 <allen at wirfs-brock.com>
> To: Axel Rauschmayer <axel at rauschma.de>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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
> axel at rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> ---------- 転送メッセージ ----------
> From: Domenic Denicola <domenic at domenicdenicola.com>
> To: Brendan Eich <brendan at mozilla.org>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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" <brendan at mozilla.org> 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" <claus.reinke at talk21.com>
> To: "Brendan Eich" <brendan at mozilla.org>, "Allen Wirfs-Brock" <
> allen at wirfs-brock.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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: 程劭非 <csf178 at gmail.com>
> To: Russell Leggett <russell.leggett at gmail.com>
> Cc: es-discuss Steen <es-discuss at mozilla.org>
> 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 <russell.leggett at gmail.com>
>
>> On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 <csf178 at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120929/f6284b38/attachment-0001.html>

DELETED_POST
2012/09/29 14:30 <es-discuss-request at mozilla.org>: