On Mon, Nov 13, 2017 at 10:54 AM, T.J. Crowder <tj.crowder@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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
