Allen and I have been discussing this on Twitter. I thought I’d bring my thoughts to list to get them somewhere with less of a character limit.
In general, I think this is a pretty nice syntax for authors. However, I'm concerned that it doesn't satisfy the "metaprogramming" use case that toMethod() solved. A more abstract and less-motivating way of putting this is to say that `mixin` doesn't give us imperative forms to allow us to build a class from the ground up, whereas toMethod() does (or at least takes care of the big issue therein, regarding `super` binding). But I think there are actual use cases at stake here. For example, consider a class-aware counterpart to [Bluebird's promisifyAll method][1]. That is, this promisifyClass function would go through a class definition, and for each of its callback-accepting methods, add a promise-returning method alongside it, with a suffix "Async" or similar. This isn't possible in ES6, since we have no way of dynamically adding methods to classes and giving them the correct `super`; it isn't possible in Allen's proposal either, from what I can tell. Allen responds that that sounds like a job for SweetJS or some other preprocessor. And that's a fine response: if we want to admit defeat on class metaprogramming, and say that classes cannot be duplicated except by outputting the correct syntactic forms (whether from a preprocessor or via `eval`), then that can be the "imperative API" for classes. But a lot of people like to do their metaprogramming in JS, and it'd be a shame if we said that for classes you have to reach outside the language to get that flexibility. Is it enough of a big deal to say "let's do toMethod() instead of `mixin`"? Probably not. Author ergonomics are much better with the latter. But I'd still like something, whether it be toMethod() or otherwise, that will let me dynamically build a class or augment an existing one. [1]: https://github.com/petkaantonov/bluebird/blob/master/API.md#promisepromisifyallobject-target--object-options---object P.S. I hope we can avoid picking on the specifics of this example too much, but to head off some objections: let's pretend that all callback methods are suffixed with "Cb", and that several of them want to do super references to non-callback/non-promise methods, and hopefully that firms up the use case. The more general point is where the meat is, though. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
