Hi Denis,
I love the inherited methods feature. Really. Seconds ago, I just clicked to show inherited methods, I checkboxed the superclass, then I saw both methods (the one I override and the one of the superclass), clicked on both, and magic...I was comparing them with a nice diff. AESOME!!!!! The only seem that didn't look obvious to me is the "sort" of the classes of the inherited protocols. It goes contrary to everwhere else. ProtoObject is on the bottom and immediate superclass on the top. Can't we make it as always? ProtoObject on the bottom and immediate on top? I know, this is a very little detail...but I also wanted to express my happiness with this feature hahaha. Cheers, |
Hi Mariano. Other people told me the same: they do not like current order. Same unnatural order is also in variable view. I implemented it this way because for me it is more convenient and intuitive. Maybe I am alone in that feeling. So I will provide setting. I try to explain my logic behind it: First, inherited methods subgroups are not about hierarchy of classes (same for variable view). It is actually hierarchy of "level of interesting methods". First superclass in tree has the most interesting methods. And deeper superclasses has less interest level. Idea that usually user wants to see methods from first superclass and not deeper. That's why I put most interesting subgroups at the top of list. Also remember that we have traits. Trait methods are more interesting then superclass methods. That's why traits subgroups are shown at the top when you browse class with traits. Also you can imaging that hierarchy which includes traits will be not natural in any order. But here it is required anyway. 2017-08-03 14:02 GMT+02:00 Mariano Martinez Peck <[hidden email]>:
|
On Thu, Aug 3, 2017 at 10:27 AM, Denis Kudriashov <[hidden email]> wrote:
OK, I understand your logic now. Again, no big deal, but I think that at least personally (even with your explanation in mind), I would still prefer the other way around. But as I said, this is a really minor detail.
|
In reply to this post by Mariano Martinez Peck
Thanks because this is months that I said the same to denis.
And I will never never explain that to students and I will add a setting to turn it the other way. I hate this! Stef On Thu, Aug 3, 2017 at 2:02 PM, Mariano Martinez Peck <[hidden email]> wrote: > Hi Denis, > > I love the inherited methods feature. Really. Seconds ago, I just clicked to > show inherited methods, I checkboxed the superclass, then I saw both methods > (the one I override and the one of the superclass), clicked on both, and > magic...I was comparing them with a nice diff. AESOME!!!!! > > The only seem that didn't look obvious to me is the "sort" of the classes of > the inherited protocols. It goes contrary to everwhere else. ProtoObject is > on the bottom and immediate superclass on the top. Can't we make it as > always? ProtoObject on the bottom and immediate on top? > > I know, this is a very little detail...but I also wanted to express my > happiness with this feature hahaha. > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com |
In reply to this post by Mariano Martinez Peck
Mariano
how many year of pharo programming do you have? And you got confused :) so imagine a newbie. And imagine when you browse code that you do not know. It violates all the inheritance mind sharing. Stef On Thu, Aug 3, 2017 at 4:29 PM, Mariano Martinez Peck <[hidden email]> wrote: > > > On Thu, Aug 3, 2017 at 10:27 AM, Denis Kudriashov <[hidden email]> > wrote: >> >> Hi Mariano. >> >> Other people told me the same: they do not like current order. Same >> unnatural order is also in variable view. >> I implemented it this way because for me it is more convenient and >> intuitive. Maybe I am alone in that feeling. So I will provide setting. >> >> I try to explain my logic behind it: >> >> First, inherited methods subgroups are not about hierarchy of classes >> (same for variable view). >> It is actually hierarchy of "level of interesting methods". First >> superclass in tree has the most interesting methods. And deeper superclasses >> has less interest level. Idea that usually user wants to see methods from >> first superclass and not deeper. That's why I put most interesting subgroups >> at the top of list. >> Also remember that we have traits. Trait methods are more interesting then >> superclass methods. That's why traits subgroups are shown at the top when >> you browse class with traits. >> Also you can imaging that hierarchy which includes traits will be not >> natural in any order. But here it is required anyway. >> >> > > > OK, I understand your logic now. Again, no big deal, but I think that at > least personally (even with your explanation in mind), I would still prefer > the other way around. But as I said, this is a really minor detail. > > >> >> 2017-08-03 14:02 GMT+02:00 Mariano Martinez Peck <[hidden email]>: >>> >>> Hi Denis, >>> >>> I love the inherited methods feature. Really. Seconds ago, I just clicked >>> to show inherited methods, I checkboxed the superclass, then I saw both >>> methods (the one I override and the one of the superclass), clicked on both, >>> and magic...I was comparing them with a nice diff. AESOME!!!!! >>> >>> The only seem that didn't look obvious to me is the "sort" of the classes >>> of the inherited protocols. It goes contrary to everwhere else. ProtoObject >>> is on the bottom and immediate superclass on the top. Can't we make it as >>> always? ProtoObject on the bottom and immediate on top? >>> >>> I know, this is a very little detail...but I also wanted to express my >>> happiness with this feature hahaha. >>> >>> Cheers, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com |
In reply to this post by Stephane Ducasse-3
> On 4 Aug 2017, at 08:39, Stephane Ducasse <[hidden email]> wrote: > > Thanks because this is months that I said the same to denis. > And I will never never explain that to students and I will add a > setting to turn it the other way. > I hate this! +1000 Calypso is super cool (I really like it, you all know me and know I would not say that if it wouldn’t be true), but it still needs a huge pass on usability/interaction point of view. also I do not think it should be a setting: some things needs to be studied and make “is like that”: - trees should be shown in the “standard" expected way (what we are used to see) - when possible, all similar iterations to old-known things should be the same - all elements should be presented in a coherent way (and always the same) - etc. etc. etc. Esteban > > Stef > > On Thu, Aug 3, 2017 at 2:02 PM, Mariano Martinez Peck > <[hidden email]> wrote: >> Hi Denis, >> >> I love the inherited methods feature. Really. Seconds ago, I just clicked to >> show inherited methods, I checkboxed the superclass, then I saw both methods >> (the one I override and the one of the superclass), clicked on both, and >> magic...I was comparing them with a nice diff. AESOME!!!!! >> >> The only seem that didn't look obvious to me is the "sort" of the classes of >> the inherited protocols. It goes contrary to everwhere else. ProtoObject is >> on the bottom and immediate superclass on the top. Can't we make it as >> always? ProtoObject on the bottom and immediate on top? >> >> I know, this is a very little detail...but I also wanted to express my >> happiness with this feature hahaha. >> >> Cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com > |
Free forum by Nabble | Edit this page |