Hi Denis, Le jeu. 11 oct. 2018 à 10:24, Guillermo Polito <guillermopolito@gmail.com> a écrit :
Hi,
On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello.
I want to ask you what you think about it. - do you prefer to see trait methods by default?
Yes.
- do you want feature to hide trait methods?
Not necessarily. But the problem are not the methods "in traits". Read my explanation below.
Current Calypso support for traits follows simple principle which I found important for me. But I can be the only guy who think this way. Maybe because I meet traits in Self. So: I simply want to see in the browser what class is actually implements. If class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to see its methods by default. When I open such class in the browser I want to see only code which class explicitly implements For me this logic is same as for superclass methods.
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.
You're making your point about the danger of duplication very clear :) Thierry
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.
On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli@gmail.com> wrote:
And by the way, we really need to name traits with a T in the name? I always found this ugly, it makes the trait support look like a hack.
I don't think so :). It's just a name convention.