== Handler access to proxies == Proxy handler traps need to receive the proxy as a parameter: first, or last?
Last allows trap implementors to leave |proxy| off. It's also a compatible extension to the proposal and its prototype implementations. Putting |proxy| last may also steer implementors away from touching proxy, reducing the bugs where you infinitely diverge. First is more normal-order (proxy, name) and some find it more aesthetically pleasing. Another alternative: the proxy could be "passed" via a data property on the handler. But the only use for the proxy reference is as a key in a weakmap, and if the handler references it, the handler could just as well be the key -- or the handler could simply hold the value associated by the weakmap. Conclusion: no rationale for adding a |proxy| parameter to all traps. == Proxy drop receiver == Sean Eagan pointed out in https://mail.mozilla.org/pipermail/es-discuss/2011-April/013916.html that the receiver parameter of Proxy handlers' get and set traps is useless, due to how these derived traps layer on fundamnetal traps. Conclusion: remove |receiver| from these traps. == Luke's report on Microsoft-internal feedback == Runtime extensions usable soonest, modules significant but full impact unclear, concern about versioning. Positive: private names, classes, let, proxies, typed arrays and binary data Concern: enhanced object literals, destructuring, quasis Indifferent: Maps/sets, iterators, tail calls, (parameter) default values, comprehensions, spread/rest Possible confusion about Map and Set requiring object typed keys -- they allow all key types. What may be wanted: "computed keys", i.e., objects that are equated not by identity, rather via equals/hashcode-style methods. ES5 not viewed as super-compelling. A few "use strict"; adoption cases, unclear what it helped or hurt. Happy to be able to feature-detect APIs, cannot feature-detect syntax (false: eval), but can't use ES5 until it is supported by most browsers in the field. Counterpoint: in that case, when it is supported enough both APIs and syntax can be used. Subsets while prototyping the next edition, coordination among implementors, to get the good stuff out. Concern about brevity of <script> vs. <script type="application/ecmascript;version=6">. Counterpoint: |use version 6;| in-band in the script content. Can use both, or just the latter. Agreement on usability including conciseness being important to work on for ES.next. An offline compiler from ES.next to ES3+R would help. Some better way to conditionally load scripts depending on UA language version support... API and feature wishlist: * Crypto APIs (no details re: getRandomValues vs. AES, etc.) * Stack traces, debugging aids * Data-binding * Binary source format for code size,load time perf wins * Shothand for typeof someGlobal == "undefined" * Compiler hooks for code transformation * Int64, Bignum * More focus on static analysis (part of each group's toolchain) Destructuring had love / hate reaction (object pattern without shorthand, less worthy objections). Modules: * Early errors make code brittle as modules evolve if you use |import foo.*|. * Async loading implications * Soft failure on timeouts? * Scenarios where developer doesn't know whether to use static or dynamic loading? * Want dependent script loading to be delayed till "truly dynamically needed" * Browser-level compoment dependency mechanism -- can support CSS and HTML too? Classes * Positive readability and debugability reactions * Desugaring important for interop with existing prototypal patterns * "class" terminology and the keyword itself raises some hackles Object literal * The ~!# and := cussing is not popular * People don't want to make properties non-writable or non-configurable * Prototype-of well-received as idea, <| syntax looks awkward * Seems like a lot of overlap with classes, want only one Quasi-literals * "I don't like Perl" reaction * String.format instead * "Love it, I would use it all the time" reaction * Name is confusing Iterators and generators * "Yes, that would be cool" * Not something that would be heavily used unless provided by common libraries Audience was mix of front end developers and library/middleware authors Proxies * Awesome... wait, do we really want unstratified ("observe")? Yeah... * Don't immediately see applications, but could see abstracting away DOM diffs * Could simplify sandbox, but would prefer direct browser support, at MS Web Sandbox or Caja granularity == Luke's work on Math and String extensions == Math functions * Java signum (-1, 0, or 1 return value) vs. C signbit (non-zero if negative including -0, zero otherwise) * What is the purpose? Translating numeric algorithms from Java, or C? * NaNs should be canonical so you can't distinguish negative from positive NaNs * Safe way to make a non-NaN float from uint32 or even uint64 data * Math.{log1p,expm1,log2,log10,hypot}, etc. * Math.{cosh,sinh,tanh,acosh,asinh,atanh} * gamma, erf? Waldemar argues for including * Open question about OS libm interoperation * deg2rad and rad2deg? Math.M_2_PI instead? neither? not sure String methods * reverse (like s.split('').reverse().join('')) along with the ones adopted in May * Waldemar: reorders uint16 units that form combining sequences, surrogates * General agreement that this is novel as a hazard and reverse is too marginal a thing to add with this hazard * want UTF-8 transcoding with byte arrays, topic for binary data == Editor's update == Allen gave an update on the editorial process and his use of https://bugs.ecmascript.org/ to track ES5.1 errata and ES6 work items. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
