Re: Providing object iterators beyond just Object.keys()
No draft written, but I am the current champion. If you'd like to get something started, we can co-champion :) Rick On Tue, May 26, 2015 at 2:45 PM Michael Ficarra mfica...@shapesecurity.com wrote: Has anyone drafted a proposal for this? Is anyone assigned as champion yet? On Tue, May 26, 2015 at 11:05 AM, Rick Waldron waldron.r...@gmail.com wrote: Silence because it wasn't a priority, relative to finishing ES6. It's not forgotten and still on track for ES7 development. Rick On Tue, May 26, 2015 at 11:59 AM Gijs Kruitbosch gijskruitbo...@gmail.com wrote: Perhaps surprisingly, I had actually asked around and looked through recent threads. Apologies for not having found the previous discussions from a year ago. It seems that after the call for a strawman in the meeting notes from April 2014, there was silence? https://esdiscuss.org/topic/object-entries-in-2015 asks the same. I don't really know whether it's more useful to continue replying here or pull up that thread (is one month old by es-discuss standards?). Either way, it would be useful to know what the current status is, which none of the posts/notes that I saw really clarify. ___ 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 -- Shape Security is hiring outstanding individuals. Check us out at *https://shapesecurity.com/jobs/ https://shapesecurity.com/jobs/* ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: why not just import new language into browser?
在 2015年05月27日 23:01, 李白|字一日 写道: 2015-05-27 2:18 GMT+08:00 duanyao duan...@ustc.edu mailto:duan...@ustc.edu: 在 2015年05月26日 11:13, eric 写道: I would like to suggest a language neutro interface for all languages inside all browsers. Web APIs are defined in WebIDL, which is language neutro. However I don't think the implementations of those APIs in browsers can be acutually language neutro. Most browsers are implemented in C++, so they can provide C/C++ APIs in addition to JS APIs. But if you want to support other languages, you'll have to write wrappers around C/C++ APIs, and these are non-trival efforts (checkout cefglue[1] and geckofx[2]). Additionally, for security and portability reasons, browsers can't expose Web APIs to web pages via unmanaged C/C++. Web Api, Native Client are all the efforts made to make the browser side to be a platform other than HTML + CSS + JAVASCRIT Parser. obviously client side languages should be subsetted and provided limited accesses to the browsers. If other languages in browsers are also managed and CPU/OS neutro, they will have very little advantages over compile to JS (espacially asm.js) solutions. This is why Dart VM and Portable Native Client can't gain much adoption. so the browsers will support all languages by plugin instead of changing javascript into an evil language. and the rest of programmers will use there languages freely. What do you mean by plugin? ActiveX? NPAPI? PPAPI? NativeClient? or something new? Supporting languages except JS natively were tried (C/C++ via ActiveX and NPAPI, VBScript, Java Applet, Flash, and Silverlight), but all failed or are failing. Why? (1) Security. ActiveX and NPAPI are proven to be insecure. Althrough newer plugin architectures like PPAPI are safer, but are not as safe as no plugin at all. that is why a neutro language interface is important. Important things are not always feasible to implement. How a language-neutro interface looks like? Do you have an idea on how to implement it in some browser engines? I don't. plugin here means even when we defined the language neutro interface, we still need many plugins to be developed by various language supporters. the easiest one would be javascript interface. because it is implemented now. but others should be able to be developed one by one if the interface is open and the packaging and importing problem the javascript has now will disappear. because all the languages can use their importing or packing mechanism before compiled into a browser executable file. this plugin is just a way to extend the language options for browsers. not like activeX and NPAPI, etc. Please describe what the plugins look like, not what the plugins are not like. the aim is to make DOM manipulating more easier for other languages. especially for mobile applications where fast speed needs badly. There is not guarantee that other languages can be faster than JS; they are more likely slower than highly optimized JS engines. (2) Complexity. Browsers are unwilling to duplicate works if some features are already availible via JS. the separating of javascript from browser will make it more simple and extensible. Obviously, browser developers disagree. Blink removed JavaScriptCore, Webkit removed V8, and MS Edge removed VBScript. the javascript engine can be replaced. and can be downloaded from the internet. the client users can be more delighted to download various fast javascript engines or engines of other languages. HTML file can have a default engine url for browsers to download. Won't work. JS(or other languages) engines are native codes and not portable, so there is no guarantee that a suitable engine is availble to every CPU/OS/Browser combination. (3) Portability. Native codes and most plugins are not portable across CPU or OS, this is unacceptable for most web apps. Portable NativeClient is an exception, but it doen't show significant advantages over asm.js. won't have this problem. the plugin is no more than an interface. Yes. As you decribed above, the plugin must contain a complete language engine. If not, how those languages are executed? (4) Maintainability. Who are supposed to maintain those plugins of additional languages in browsers? Even some big companies are unwilling to maintain plugins for some platforms. For example, MS never implemented Silverlight on non-windows platforms and will drop it in Edge browser; Adobe had discontinued Flash for android and linux. Who want to use a language that is not guaranteed to work in future? asm.js is a way to make this happen in the mask of javascript. Compiled asm.js code will run as long as browsers continue to support JS; the tool chains of asm.js are simiple to implement and are open-sourced (emscripten).
Re: why not just import new language into browser?
On Wed, May 27, 2015 at 5:01 PM, 李白|字一日 calid...@gmail.com wrote: Web Api, Native Client are all the efforts made to make the browser side to be a platform other than HTML + CSS + JAVASCRIT Parser. Web API (by which I assume you mean the APIs defined in the W3C and WHATWG standards) is definitely not an effort made to make the browser side to be a platform other than HTML + CSS + JS. obviously client side languages should be subsetted and provided limited accesses to the browsers. If you really believe that, prove that it is practical and does not incur a performance hit by implementing it on your choice of open-source browser. Everyone seems to believe otherwise. DOM bindings are tricky enough as they stand, they have been heavily optimized by every browser, and they won't want to see all that work flushed so that browsers can finally start having new kinds of incompatibilities. “Hey, I built this page in Python! It is Chrome-only, because only Chrome implemented the VM-DOM bridge of my dreams. Also, running the very same code in PythonJS is faster on other browsers, partially because they didn't complicate their DOM bindings, partially because JS engines are freakishly fast: http://2.bp.blogspot.com/-pylzspKRu6M/UqbAv3qIGTI/AkE/NnsAM5DZ_8M/s400/nbody.png.” There is no point in caring about what language browsers provide, because they indirectly support any. You want to write it in C++? Please do; there's a compiler for that, it's called Emscripten. It uses sourcemaps so that your debugger shows your C++ source code, just like gcc/gdb uses DWARF on ELF assembly. What you want is already there, you simply have wrong assumptions about what is there. the aim is to make DOM manipulating more easier for other languages. Any compiler can offer that. Cheerp has that. Dart2js has that. Scala.js has that. especially for mobile applications where fast speed needs badly. Then don't make DOM bindings slower by requiring multiple VMs. Like I said, I would be very surprised if you could make things faster than an optimized asm.js output by somehow adding the ability to run multiple VMs in a browser. the javascript engine can be… downloaded from the internet Why are you only suggesting things that would make webapps slower, if what bothers you is speed? (Also, do you really want any webpage to be able to install malware instantly? How would the browser see the difference between a JS engine and malware hidden in a JS engine?) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: why not just import new language into browser?
2015-05-27 2:18 GMT+08:00 duanyao duan...@ustc.edu: 在 2015年05月26日 11:13, eric 写道: I would like to suggest a language neutro interface for all languages inside all browsers. Web APIs are defined in WebIDL, which is language neutro. However I don't think the implementations of those APIs in browsers can be acutually language neutro. Most browsers are implemented in C++, so they can provide C/C++ APIs in addition to JS APIs. But if you want to support other languages, you'll have to write wrappers around C/C++ APIs, and these are non-trival efforts (checkout cefglue[1] and geckofx[2]). Additionally, for security and portability reasons, browsers can't expose Web APIs to web pages via unmanaged C/C++. Web Api, Native Client are all the efforts made to make the browser side to be a platform other than HTML + CSS + JAVASCRIT Parser. obviously client side languages should be subsetted and provided limited accesses to the browsers. so the browsers will support all languages by plugin instead of changing javascript into an evil language. and the rest of programmers will use there languages freely. What do you mean by plugin? ActiveX? NPAPI? PPAPI? NativeClient? or something new? Supporting languages except JS natively were tried (C/C++ via ActiveX and NPAPI, VBScript, Java Applet, Flash, and Silverlight), but all failed or are failing. Why? (1) Security. ActiveX and NPAPI are proven to be insecure. Althrough newer plugin architectures like PPAPI are safer, but are not as safe as no plugin at all. that is why a neutro language interface is important. plugin here means even when we defined the language neutro interface, we still need many plugins to be developed by various language supporters. the easiest one would be javascript interface. because it is implemented now. but others should be able to be developed one by one if the interface is open and the packaging and importing problem the javascript has now will disappear. because all the languages can use their importing or packing mechanism before compiled into a browser executable file. this plugin is just a way to extend the language options for browsers. not like activeX and NPAPI, etc. the aim is to make DOM manipulating more easier for other languages. especially for mobile applications where fast speed needs badly. (2) Complexity. Browsers are unwilling to duplicate works if some features are already availible via JS. the separating of javascript from browser will make it more simple and extensible. the javascript engine can be replaced. and can be downloaded from the internet. the client users can be more delighted to download various fast javascript engines or engines of other languages. HTML file can have a default engine url for browsers to download. (3) Portability. Native codes and most plugins are not portable across CPU or OS, this is unacceptable for most web apps. Portable NativeClient is an exception, but it doen't show significant advantages over asm.js. won't have this problem. the plugin is no more than an interface. (4) Maintainability. Who are supposed to maintain those plugins of additional languages in browsers? Even some big companies are unwilling to maintain plugins for some platforms. For example, MS never implemented Silverlight on non-windows platforms and will drop it in Edge browser; Adobe had discontinued Flash for android and linux. Who want to use a language that is not guaranteed to work in future? asm.js is a way to make this happen in the mask of javascript. so the efforts made in es6,7 will be found useless. [1] https://bitbucket.org/xilium/xilium.cefglue/ [2] https://bitbucket.org/geckofx ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Providing object iterators beyond just Object.keys()
You can simply use the Symbol.iterator property to configure how you want the property and value of the object to be iterated. This will allow you to use any from of iteration; e.g. For loop while loop forEach if you do the generic way I'm thinking . If this help. Post me some link to resources that you have found on your journey as a js dev. JS4Lf On May 27, 2015, at 9:47 AM, Rick Waldron waldron.r...@gmail.com wrote: No draft written, but I am the current champion. If you'd like to get something started, we can co-champion :) Rick On Tue, May 26, 2015 at 2:45 PM Michael Ficarra mfica...@shapesecurity.com wrote: Has anyone drafted a proposal for this? Is anyone assigned as champion yet? On Tue, May 26, 2015 at 11:05 AM, Rick Waldron waldron.r...@gmail.com wrote: Silence because it wasn't a priority, relative to finishing ES6. It's not forgotten and still on track for ES7 development. Rick On Tue, May 26, 2015 at 11:59 AM Gijs Kruitbosch gijskruitbo...@gmail.com wrote: Perhaps surprisingly, I had actually asked around and looked through recent threads. Apologies for not having found the previous discussions from a year ago. It seems that after the call for a strawman in the meeting notes from April 2014, there was silence? https://esdiscuss.org/topic/object-entries-in-2015 asks the same. I don't really know whether it's more useful to continue replying here or pull up that thread (is one month old by es-discuss standards?). Either way, it would be useful to know what the current status is, which none of the posts/notes that I saw really clarify. ___ 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 -- Shape Security is hiring outstanding individuals. Check us out at https://shapesecurity.com/jobs/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Class decorators and async process
Alexandre Louis Marc Morgaut wrote: Sync is out of bounds in browsers, and for Node.js apart from require -- a rift indeed between the two embeddings. Just to be fair, Sync is still appreciated in some situations in JS like - in Dedicated Workers, Good point. Still not in specs but proposed via W3C or WHATWG (I forget). Anyone have a fresh link? - in other SSJS platforms like RingoJS, Wakanda, APE, … Sure, but I wrote in browsers :-|. Didn't mean to exclude non-Node SSJS platforms. Then there are the isomorphic approaches that may compile out sync into async, e.g. Meteor. - as it is also in Node.js when writing CLI applications (then tricks are occasionaly used in addition to Sync APIs);-) Right, thanks. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: why not just import new language into browser?
I would like to suggest that everyone let this thread die. It's way out of scope for es-discuss, and three kinds of bogus just considering the Subject: line. If anyone wants to chat about it, HN has regular recurring why not blub? and why not bytecode threads. /be (co-moderator with @awbjs) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Class decorators and async process
On 26 May 2015, at 01:09, Brendan Eich bren...@mozilla.org wrote:
Gray Zhang wrote:
It’s OK, I just wait for |this.weapon| to resolve, but then my |hit| method
becomes async, and everything based on |@inject| property should be async,
which is not actually what I want.
Async can be contaminating, yes.
That’s exactly a point that reached my interest in the given example
My brain looking at this contamination wondering things like:
- Then we would need “await @inject(‘knife’)” ?
- Then we would need “async class Hero {…}” ?
- Then users should take care to do “await new Hero()” ?
- and/or would it mean that we could do instead “class extends Promise { … } ?
Ok… Are async Classes / Constructors crazy or just natural evolutions we
could/should be prepared to see in the future !?
Just wondering, I’m curious, I’d understand either that to be crazy or natural
;-)
Sync is out of bounds in browsers, and for Node.js apart from require -- a
rift indeed between the two embeddings.
Just to be fair, Sync is still appreciated in some situations in JS like
- in Dedicated Workers,
- in other SSJS platforms like RingoJS, Wakanda, APE, …
- as it is also in Node.js when writing CLI applications (then tricks are
occasionaly used in addition to Sync APIs) ;-)
Regards,
Alexandre
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
