avoids the gorilla-banana problem by getting only the methods you need
works both in function contexts and class contexts
you clearly see what your object has mixed in in its definition context
you clearly see where your mixed in capabilities come from
It's not clear how well the existing TC39 proposal for mixins deals with
some of these (especially with sharing private state between your code and
the mixin context.
As a follow up on my previous mixin proposal and the discussion at (
https://esdiscuss.org/topic/definition-mixins) I published a mixin library
on npm: smart-mix (https://www.npmjs.com/package/smart-mix).
It:
- mixes in public methods
- mixes in private methods
- allows sharing private state and public state
- each instance of the mixin has its own state
- avoids keys collisions
- works both with symbols and string keys
- avoids the gorilla-banana problem by getting only the methods you need
- works both in function contexts and class contexts
- you clearly see what your object has mixed in in its definition context
- you clearly see where your mixed in capabilities come from
It's not clear how well the existing TC39 proposal for mixins deals with
some of these (especially with sharing private state between your code and
the mixin context.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180901/6cfaf8cb/attachment.html>
As a follow up on my previous mixin proposal and the discussion at ( esdiscuss.org/topic/definition-mixins) I published a mixin library on npm: smart-mix (www.npmjs.com/package/smart-mix).
It:
It's not clear how well the existing TC39 proposal for mixins deals with some of these (especially with sharing private state between your code and the mixin context.