Function.prototype.new

💡 Ideas
58

As there's no progress in here and I don't expect any at this point, I'd like to summarize the outcome of this discussion, partially as summary, partially to end this thread with something worth everyone time in it and possible users reading, in the future, the conclusion.

  • it is documented that there is a need for better interoperability between JS and WASM targeting foreign PLs, as these might not be able to parse new Class in the wild and within their foreign PL syntax ... the proposal is to make Class.new(...args) a standard/expected behavior, to solve all issues
  • it is unlikely that this proposal will ever land in ECMAScript, as pretty much everyone opposed to the idea that Function.prototype.new should be in JS just because many other PLs can't deal with JS syntax in their foreign PL
  • it is acknowledged that such proposal would solve the issue without caveats, but alternative solutions have been presented to help these foreign WASM targeting PLs to solve the issue by their own
  • the most robust proposed alternative is that every WASM targeting PL should use a Proxy get trap to figure out if new is desired, if it's not already present in the target, and when that's the case, return what's being proposed in here in the first place, but as workaround out of suggested checks, so that it's possible for these PLs to use Class.new(...args) without needing ECMAScript changes to help them
  • accordingly, it's acknowledged that Function.prototype.new can't ever exist in JS, otherwise these WASM targeting foreign PLs would suddenly break out of the blue, in case a new method lands in Function.prototype and it doesn't do exactly what's being proposed in here ... so Function.prototype.new in this thread has been granted/sealed, and locked in, forever as non-existent, because after knowing WASM targeting PLs will use what's been suggested in here, it would be pretty evil to land in there anything else that's slightly different from this proposal (Python is also heavily used at academic level: changing JS means changing every student or professor code based on WASM and JS bindings expectations)
  • in turns, this means that both polyfill to have Function.prototype.new defined, or consider there won't ever be an inherited Function.prototype.new in JS, are both valid solutions in the short to long term (the polyfill is not future hostile, the module trust no Function.prototype.new will ever exist out of specs or ... if it does ... it's exactly the proposed one in here)

Please feel free to comment any of these points so that I can update eventually the summary but I believe the scafolded logic is sound, as result of this thread.

Regards.