Doh! Nevermind. I get it.
On Mon, Feb 23, 2015 at 4:13 PM, Mark S. Miller <[email protected]> wrote: > 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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
