On Feb 23, 2015, at 3:40 PM, Domenic Denicola wrote: > 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. >
Just wanted to add that one of the points I tried to make in the tweets was that it is probably good to think about [[HomeObject]] similarly to the way we think about [[Scope]]. There are lots of interesting metaprogramming things you could imagine trying if a function's [[Scope]] as mutable. But the risks it would expose are just too much greater than its utility. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
