domenic at domenicdenicola.com (2014-08-18T18:36:09.405Z)
On Mon, Aug 11, 2014 at 6:33 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote: > Presumably a future version of ES that contains traits would define > set-like, map-like, and other traits that could be used. Hopefully. But any future JS traits system should somehow play well with JS classes. The semantics of classes we accepted into ES6 makes that difficult but probably not impossible. Just for the record: Some of the rejected class proposals were designed to play well with future traits systems. In the end I agree with the pragmatics that caused these to be rejected in favor of the current one. But we paid the costs of making traits harder and more awkward, to the point that we may never have one we deem acceptable. We'll see.
On Mon, Aug 11, 2014 at 6:33 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote: > When I last looked at this, it seemed like a perfect use case for [Traits]( > http://soft.vub.ac.be/~tvcutsem/traitsjs/tutorial.html). A "Set-like" > trait would require definitions for add, delete, and [Symbol.iterator], but > provide has, forEach, entries, keys, values, clear, and size, plus any > future interfaces. > > Then you would implement such set-likes by mixing in the set-like trait > into your prototype, which contains type-restricted definitions for add, > delete, and [Symbol.iterator] (plus probably some of the other methods for > performance reasons). > > Presumably a future version of ES that contains traits would define > set-like, map-like, and other traits that could be used. > Hopefully. But any future JS traits system should somehow play well with JS classes. The semantics of classes we accepted into ES6 makes that difficult but probably not impossible. Just for the record: Some of the rejected class proposals were designed to play well with future traits systems. In the end I agree with the pragmatics that caused these to be rejected in favor of the current one. But we paid the costs of making traits harder and more awkward, to the point that we may never have one we deem acceptable. We'll see. -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140811/0bdb5c95/attachment.html>