"William O. Dargel" <wDargel at shoshana.com> wrote...
>So the change to the first method needs to be replicated in the second. But this is definitely violating the "OnceAndOnlyOnce". It looks like the first can be implemented in terms of the second by passing a nil sourcePointer for #lostMethodPointer:, but maybe someone with a better understanding of the linking and
>management of the source code could confirm this?
>
>But actually for my own use, I think I'll just cut out the test for listHasSingleEntry all together. My thinking goes like this. If I really want to see it, the extra menu popping up to confirm that I want to see it, just gets in the way. And on the flip side, I find it just as effective to have a browser pop up with a
>single version of the method showing as it is to have a menu telling me there are no older versions. It's let cognitively jarring when I'm asking about the versions of a method to simply see... "ah yes, there's just the one version, and here's its author, date and time" or... "there are the n versions of the method with
>these authors, etc.", as opposed to sometimes seeing the versions that I asked for and sometimes getting a 'no older versions' menu instead. But that's just my $0.02 worth.

Sigh.

We basically agree.  This particular clever tweak has become an archetype of the "if it ain't broke dont fix it" situation.  It was proffered as an improvement and we didn't live with it long enough before sending it out to all.  In fact there is yet another fix that answers your further concerns (more snickering), but I agree it was better where it started -- same response all the time, and probably easier to click close than to shift gears and deal with a menu.

	- D