2016-12-30 17:04 GMT+01:00 Ben Coman <[email protected]>: > > So you think existence of "Class variables" is also confusing because it > > looks like parent group for instance variables? > > Yes its confusing. I didn't even notice that "Class variables" could > be expanded to show > DependentsFields. I just assumed "Class variables" was the expanded > parent of > MultiByteBinaryOrTextStream, isBinary, converter. Hence my comment > that "class variables" item should be renamed "instance variables". > Now I see my comment was off target. I think the best fix is to have > a parent "instance variables" as well as "class variables", and on the > class side the parent should be "class instance variables." Such > labels educate newbies. > > > > >> > >> > >> Now I wonder if we can do without the Methods/Vars buttons by having > >> the following top level tree items. Also as a newbie before developing > >> the instinct to *know* which instance/class-side I was on, I got burnt > >> a few times following tutorials accidentally putting methods on the > >> wrong side. It would be interesting to try deprecating the > >> Inst-Side/Class-Side buttons, and have something like the following > >> items... > >> + instance-side methods > >> - accessing > >> - initialization > >> - extensions > >> - GT-InspectorExtensions > >> + class-side methods > >> - instance creation > >> - extensions > >> + variables > >> - instance variables > >> - class variables > >> - class instance variables > >> > > > > It could be good or not. > > Problem with this approach is same as why we use 4-column panes instead > of > > single tree menu for everything like other IDE does. > > We don't want to scroll to achieve some group element. > > Imaging that you browse some morph subclass which have a lot of > protocols. > > You are in some middle protocol and not see parent expanded group in > list. > > And now you want to look at class side or variables. Tree view will force > > you to scroll instead of simple press on switch button like it is now. > > okay. It would still be useful to at least have "Instance methods" parent > at the same level as "inherited methods" and "extensions" > * its disconcerting to have the protocols floating without a parent > * currently nowhere to select "All methods" - it seems you need to > deselect to see all methods. So with > * it could give another visual indication of which side you are on, by > changing to "class methods" when the <Class side> button is pushed.
Personally I do not like it. I not understand why "accessing" under "inherited methods" is looks like child inside parent but "instance methods" under it will not confuse you too. Also in Calypso protocol is not exists anymore. There is just specific kind of method group which shows methods marked with given tag. Group "extensions" is another kind of method group which shows class extensions. In future we will have much more groups from old nice project "dynamic protocols" (there are github issues for them). So in general my idea that tagged method groups is not something special comparing to any other method groups. Not need for special parent for them. (In Pharo7 we will try to move to tags idea and remove protocols and class/method categories. New API for tags is already in Pharo 6 19341 <https://pharo.fogbugz.com/f/cases/19341/New-class-and-method-tags-API>. User will be able to mark method or class with set of tags. Each tag is just symbol)
