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

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.

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.