Hi Denis, Le jeu. 11 oct. 2018 à 10:24, Guillermo Polito <[email protected]> a écrit : > > Hi, > >> >> On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <[email protected]> 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 <[email protected]> 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.
