tag:blogger.com,1999:blog-7515306875906042828.post107962954496187189..comments2024-02-05T11:56:11.174-08:00Comments on Objology: I've Inherited an Interesting DilemmaTravis Griggshttp://www.blogger.com/profile/01599271142862167244noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7515306875906042828.post-29168646012398256452011-08-24T09:46:19.807-07:002011-08-24T09:46:19.807-07:00Up front, I agree with you Reinout about the end s...Up front, I agree with you Reinout about the end solution. And will probably do mostly just that.<br /><br />But 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.<br /><br />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.Travis Griggshttps://www.blogger.com/profile/01599271142862167244noreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-73243290580130537802011-08-24T07:47:29.302-07:002011-08-24T07:47:29.302-07:00From this point, where the term "Hierarchy&qu...<i>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</i><br /><br />--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). <br />Smalltalkers OTOH have a Smalltalk model in their head that aligns more with how the VM does method resolution.<br /><br />To answer your question:<br />1) what Holger said: remove the silly 'both sides' answers, make the result precise.<br />2) do show class behavior implemented above Object class -- this seems the most useful in the developers workflow.<br />3) the name of the menu item is just fine.Reinout Heecknoreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-4705866462443959352011-08-24T02:04:33.321-07:002011-08-24T02:04:33.321-07:00There's another related issue: When browsing h...There's another related issue: When browsing hierarchy implementors, both class and instance side are searched. <br /><br />Browsing the hierarchy implementors of <br /><br /> ApplicationModel class>>initialize<br /><br />finds <br /><br /> Object>>initialize<br /> Object class>>initialize<br /> ClassCreationDialog>>initialize<br /> ClassCreationDialog class>>initialize<br /><br />and so on.<br /><br />Renaming "hierarchy implementors" as "super/sub implementors" will be even more confusing with regard to this behavior.<br /><br />"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.<br /><br />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.HolgerKnoreply@blogger.com