Hi Guille. ÑÑ, 11 окÑ. 2018 г. в 9:24, Guillermo Polito <guillermopolito@gmail.com>:
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.
Duplication just needs to be avoided like in any other cases. I found that system can provide a single method which will allow correctly implement all visibility features but it will not expose to users trait arithmetics. It should just tell how given method is used by given class. aClass howAreYouUsingThisMethod: aMethod It can return different kind of objects like: - method is not used at all - it is an active method in the class - it is overridden method - method is overridden by package (for package overrides scenario) - method is removed (in trait composition) - method is aliased (in trait composition) It is kind of extended version of #isOverridden method. And can be useful in general. Anyway my question was not about implementation details of trait visibility feature. This feature will be removed and I just wanted to know if there are people who will be disappointed by this. But it seems nobody care.
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.