Fwd: Definition mixins

Raul-Sebastian Mihăilă raul.mihaila at gmail.com
Mon Nov 13 09:39:35 UTC 2017

On Mon, Nov 13, 2017 at 10:54 AM, T.J. Crowder <tj.crowder at farsightsoftware.
com> wrote:
> Could you add a "Motivations" section outlining why this is needed and
> what alternatives currently exist without new syntax?
It would be indeed worth adding such a section in the proposal, but for now
please take a look at the first message in this thread in which I do
mention why this syntax is useful and current alternatives.

> Separately, without yet having delved into the details, various parts of
> the "without mixins" code look suspect, for example:
> ```js
> const isSafeMove = mix.isSafeMove = boardMixin.isSafeMove(mix);
> ```
> That *calls* the `boardMixin.isSafeMove` function, passing it the `mix`
> constant, and assigns its return value to `mix.isSafeMove` and a new
> constant `isSafeMove` (which confusingly doesn't seem to be used anywhere).
> Should it really be *calling* the function? Not binding or something?
> -- T.J. Crowder

Please do delve into the details (especially the first message in this
thread). The first message shows how the mix object is used. Without mixins
syntax, the mix object has two purposes, it holds the mixin functions that
are provided by mixin function providers so that you can call a mixin
function in another mixin function. This mix object is passed to the mixin
function providers, so that the mixin functions that they create can use
the object. However, since an essential part of this proposal is the
ability to share private state with the mixin functions, the mix object
also contains the private state to be shared.

The reason the `isSafeMove` constant is created is to be able to easily
call the function in the current context, without having to use the mix
object. It's a nice to have. The mixin syntax not only makes this possible,
but it also provides the separation between holding the mixin functions in
an object so that they are accessible in the mixin functions themselves and
sharing whatever private data needs to be shared with the mixin functions.
This separation would have also been possible without the mixin syntax.
However, the syntax is much simpler with this proposal: the constant
binding is created, or the function can become a public method of the
object, you don't need to create and handle the mix object and this also
works with private fields in a class context. Also, the second version of
the proposal is based on the possibly controversial idea of indirect
bindings in a function context.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171113/b693a8e8/attachment-0001.html>

More information about the es-discuss mailing list