> But to get back to shaver's point: you are requiring a stylized, non-standard, > popular-library-incompatible dialect of JS to be used from the start to work > inside FuseJS's sandboxes, IIUC. Right?
Mike was getting OT onto the specifics and merits of sandboxed natives/FuseJS. I was originally answering Allen's prompt for examples of other non Array uses for __proto__. > That's ok, not criticizing per se. Just noting it's yet another dialect. > There are many such, > some with translators that can handle the wrapping, even for primitives and > literals, for you. Non that provide the flexibility of extending prototypes of natives directly without the risk of conflict and none that **work** in browsers/environments from Safari 2.0.0 through IE9. > Harmony is not about standardizing whatever hacks you needed to make your > dialect work. Thanks for the `hacks` comment. > It's about core language features that complete and correct (by extension if > not incompatible change) > the incomplete and sometimes messy core language, even as of ES5. I and others find __proto__ useful and gave a good use-case as prompted. I am ok with __proto__'s eventual removal but as you stated earlier there should be a replacement for use-cases. The __proto__ property **is** a de facto standard and should be standardized in some form to ensure compatibility, consistency, and security. As mentioned before Array.create() is not enough, something like Object.subclass() as previously proposed would be flexible for most use-cases and eliminate some of the perf/security concerns implementers have. -JDD _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
