This second is the instance side of NameSpace, the needsComment method selected.
In both cases, if you invoke the menu of the selectors list, and choose the Hierarchy Implementors option, you get the following two results, respectively...
So what's the issue? The issue is the presence of ClassDescription in the Implementors browsers. Should it be there or not?
On the one hand we have the notion of "hierarchy." In RB land, a Hierarchy Browser is a pretty common thing. It is a limited view of classes always going as high as Object. If you are on the instance side, it tops at Object. If you are on the class side, it tops at Object class. From this point, where the term "Hierarchy" refers to a browsing view or scope, it is surprising to see these entries for ClassDescription here when you ask for Hierarchy Implementors. What you expect to see, is only methods that you'd find as you navigated around in the Hierarchy Browser.
Then there is a more pedantic side. It tends to be those who like to think of themselves as "I have ascended into the thirteenth circle of Smalltlak Uber-Knowledge." They know the zen-secret that there's a "crossing of the streams" that occurs at Object class. When a method is not found at Object class, the lookup for the method doesn't stop there, but continues up on the instance side at Class, then ClassDescription, then Behavior, and finally Object (instance). The little up/down arrows we place next to methods, even show this. If you look at the first one, it shows that there is a super implementor of needsComment for AlphaBlendedIcons, that is found farther up the search tree.
These two notions of "hierarchy" when viewed from the class side, are at odds with another. When someone sees that menu option, which kind of "Hieararchy" are they more likely to think about at that moment. Should it be left the way it is, but reword the menu option to be "super/sub implementors?" What would you want it to do?
There's another related issue: When browsing hierarchy implementors, both class and instance side are searched.
ReplyDeleteBrowsing the hierarchy implementors of
ApplicationModel class>>initialize
finds
Object>>initialize
Object class>>initialize
ClassCreationDialog>>initialize
ClassCreationDialog class>>initialize
and so on.
Renaming "hierarchy implementors" as "super/sub implementors" will be even more confusing with regard to this behavior.
"super/sub implementors" is ambiguous. A "super" send will "cross the streams". There's no such thing as a "sub" send, though. On the other hand, Object's superclass is nil. So I would associate "super/sub" with the class hierarchy, not with method lookup.
99% of the time I browse hierarchy senders/implementors, I would prefer if only methods on the same side (class/instance) and only up to Object would be visible. For the remaining 1% I can still browse the global senders/implementors.
From this point, where the term "Hierarchy" refers to a browsing view or scope, it is surprising to see these entries for ClassDescription here when you ask for Hierarchy Implementors. What you expect to see, is only methods that you'd find as you navigated around in the Hierarchy Browser
ReplyDelete--Not so: the above only holds for the select set of people that know the innards of the RB. (as long as the RB gives no visual clue as to which scope it is using).
Smalltalkers OTOH have a Smalltalk model in their head that aligns more with how the VM does method resolution.
To answer your question:
1) what Holger said: remove the silly 'both sides' answers, make the result precise.
2) do show class behavior implemented above Object class -- this seems the most useful in the developers workflow.
3) the name of the menu item is just fine.
Up front, I agree with you Reinout about the end solution. And will probably do mostly just that.
ReplyDeleteBut I think it is incorrect to assert that this is driven by the "select set of people that know the innards or the RB." In fact, the 3 or so people that pointed this out in the first place, none of them were super versed on RB inner guts.
What they do know is that when they say "Browse Hierarchy" on a class, they see a view of the Smalltalk system that has a limited scope. They click around in it. They navigate through it. And they then expect that notion of "Hierarchy" to apply, rather than in the general sense.