What you think about visibility of trait method in browser?
Hello. In next Calypso version the option to enable or disable trait method visibility will not be available anymore (not my choice). All trait methods installed to the class will be just a class methods like it was in Nautilus. No way to hide them. I want to ask you what you think about it. - do you prefer to see trait methods by default? - do you want feature to hide trait methods? 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. It was my original intention for trait support in Calypso. And I would like to hear if people share it or not. (there are missing trait feature in the current approach but it is not a subject of my question. Think that everything is supported correctly) Best regards, Denis
I think that by default methods coming for traits should be visible in the browser, but needs to be somehow identified. Pharo traits was conceived in a way that from the class point of view you see no difference if it was flattened or not, and Self traits are not exactly the same because they use the delegation scheme in the method lookup. I think that a feature to hide trait methods is unneeded, but the possiblity to easily filter methods coming from a trait it a good one. Just my two cents. 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. On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello.
In next Calypso version the option to enable or disable trait method visibility will not be available anymore (not my choice). All trait methods installed to the class will be just a class methods like it was in Nautilus. No way to hide them. I want to ask you what you think about it. - do you prefer to see trait methods by default? - do you want feature to hide trait methods?
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. It was my original intention for trait support in Calypso. And I would like to hear if people share it or not. (there are missing trait feature in the current approach but it is not a subject of my question. Think that everything is supported correctly)
Best regards, Denis
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. 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.
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.
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.
Hello In my case, I would like to see USED (ie. not removed or replaced) trait methods by default with clearly visible mark that they come from trait (which is how Nautilus presents them). Reason is that quickly seeing whole API brought by this class is more important to me than seeing what the class actually imprements. I would LOVE feature to hide trait methods. I have few classes with like 20 trait methods and 2 own ones and it would be great to temporarily switch to see just the 2 (but when I open the class again later I would like to see all of them again). It seems to me there ought to be multiple opinions on this, so having option in settings (to show trait methods or hide them by default) would be best solution for both groups. Jan Denis Kudriashov wrote
Hello.
In next Calypso version the option to enable or disable trait method visibility will not be available anymore (not my choice). All trait methods installed to the class will be just a class methods like it was in Nautilus. No way to hide them. I want to ask you what you think about it. - do you prefer to see trait methods by default? - do you want feature to hide trait methods?
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. It was my original intention for trait support in Calypso. And I would like to hear if people share it or not. (there are missing trait feature in the current approach but it is not a subject of my question. Think that everything is supported correctly)
Best regards, Denis
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
participants (5)
-
Denis Kudriashov -
Gabriel Cotelli -
Guillermo Polito -
Jan BlizniÄenko -
Thierry Goubier