On 2009-11-17, at 08:29, Rami Ojares / AMG Oy wrote: [...]
> Currently I am wondering could I have multiple mixins for a class. > <class name="jee" with="foo, bar, snafu"/> Yes. This is already permitted. As it happens, Henry is working on extending the mixin feature to instances too. We realized that it was a hole in the "instance first" model: http://jira.openlaszlo.org/jira/browse/LPP-8602 > which led me to even trickier thoughts > When inheriting you can override methods and attributes. > But would be great if one could override nodes too. The model of node inheritance is that you get a union of all the nodes, rather than overriding. I can see what you are getting at, but that would be a huge change in the language. I think we would have to have some really compelling use cases to consider that level of change. [...] > And finally a concrete question: > Who overrides who when using mixins > My own guess > Primary: class itself > Secondary: all parent classes in order of proximity > Tertiary: mixin It works like this: <class name="a" extends="b" with="c, d, e"> To find a property (attribute, method, etc.) in an instance, look in this order: <instance>, a, c, d, e, b, <b's inheritance list> So: mixins override the superclass, in the order they are specified. There is a lot of theoretical literature on mixins. Most of it boils down to: mixins are "powerful but dangerous". This is why Java and C++ only have interfaces. There is a compromise between mixins and interfaces, called "traits", which basically boil down to: a trait is a mixin with no overrides, on the theory that you cannot get confused about override order if there are none. We don't think interfaces or traits are powerful enough, so we went for mixins. They are a power tool, so they need to be used with care. But with that care, they can be a very powerful tool.
