Open rakudrama opened 9 years ago
Banning repeated mixins occurred to me as well. It's distasteful, but seems relatively harmless (he says carelessly ...). However, once you add mixin composition (which people are already agitating for) it becomes more of concern, as it violates encapsulation.
One could choose to a rewrite only if a mixin was repeated (in fact, only if the mixin was repeated and had super calls). This would occur quite rarely, so the extra space wouldn't be as much of an issue.
I'd like to understand how to implement this efficiently when compiled to JavaScript. If possible I'd like to find a solution where
Our experience to date has been that super calls are sufficiently alluring that it is important to make them both compact in the generated code and efficient in dispatch. Ditto mixins.
How should the following program work? Given the usual JavaScript context of
M.foo
, andC
we do not have enough information to determine which mixin application, i.e. which S_dynamic, to use:
If we can somehow avoid the above problem (e.g. making it an error to mix in the same class twice), then
M.foo
's call tosuper.foo
could be implemented asthis.from$M$foo$1(...)
with each S_dynamic definingfrom$M$foo$1
as an alias to the appropriate method (i.e. a separate property in a prototype chain object that has the same value as the main property).