Yes.
Not necessarily. But the problem are not the methods "in traits". Read my explanation below.��
Well, the main problem of this approach is that traits in self are fundamentally different than traits in self. And the main answer here is not flattening or not flattening, but the idea of "trait composition". A class does not just use "some traits". It uses a trait composition, which includes also other rules like aliases, overrides and removals. With the new implementation there is also deep aliasing. And moreover, since traits are stateful, you need to support the same for slots.
Then, regarding the current implementation, it is duplicating all the semantics of traits in the UI, and incompletely because it is not covering at all complex trait compositions.
The problem with duplication is that then, if there is a bugz, we may have to fix it several placez.
The problem with duplication is that then, if there is a bug, we may have to fix it several places.
And the other problem is that Traits already provide a good API to discover all this things automatically without duplicating any of it:
��- localMethods
��- methods
��- allMethods
And then you can always ask the origin of a method.
This API is of course perfectible, but I think it's better to enhance it, than to duplicate it and work it around.