I'm not sure I get it. I am very impressed by Allen's point about using lambda abstraction (Allen said "procedural abstraction") to parameterize a super binding.
Could you show a small self contained example that uses toMethod to do some metaprogramming that cannot be done with Allen's "mixin", where both are without source manipulation? At this point, I care more about the logical issue than whether the example seems well motivated or realistic. On Mon, Feb 23, 2015 at 3:40 PM, Domenic Denicola <[email protected]> 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. > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
