On 22 June 2013 19:48, Chris Muller <ma.chris.m at gmail.com> wrote:
> On Sat, Jun 22, 2013 at 3:42 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 22 June 2013 00:37, Chris Muller <asqueaker at gmail.com> wrote:
>>> This would seem to change the capability that a browser can have the
>>> same message in the list more than once.
>>
>> A Brower can't have the same message in the list more than once - that
>> would imply a duplicate system category, or two classes with the same
>> name within a message category, or...
>
> No.  The usage of data (in this case, collections of methods) by a
> browser is wholly independent of the Smalltalk code structure.

We're talking past each other a bit, I think. We have several
different browsers - tools used to browse things - but we have only
one Browser - a browser of a class. It _cannot_ have duplicates in its
various lists, because we
* don't allow duplicate system categories,
* don't allow duplicate class names,
* don't allow duplicate message categories within any particular
class' organisation, and
* don't allow duplicate selectors in a class' method dictionary.

For _other_ browsers, like one viewing senders-of or something, we
might have things that are _apparently_ duplicates - methods with the
same name, for instance - but wouldn't be duplicates because they
rendered different MethodReferences. I suppose I can imagine a
thing-that-browses where you _would_ want duplicates, but that's not
Browser.

> Consider an example where we're already close to needing "duplicate"
> messages in a list -- the "Recent Submissions" browser.  The way it
> behaves today, you're correct, it doesn't have "duplicates" but it's
> quite feasible one little tweak could be desirable that would always
> show "the actual log record" of changed methods by the developer, such
> that, even when a method is changed twice, it appears in the list
> twice at the positions in which it was changed.  This might be useful
> for understanding what methods are "causing trouble that day".

Right. So here things are _apparently_ duplicates, but will actually
refer to real, distinguishable, objects under the hood. Different
versions of the same method. Actually, that's a good example, because
reverting a method actually does introduce a real, actual duplicate.
(Must do, because there's little point in "revert".) And in this case,
yes, I agree that you'd pretty much have to use indices.

>>> Is this to support some functionality?  Or just a "clean up"?
>>
>> It's cleanup because I made Browser use Symbols instead of indices a
>> year or two ago. The use case was that Browsers would lose your place
>> when things happened, because an integer index has no semantic
>> meaning. Inserting a new item into the list, or removing same, caused
>> the Browser to behave oddly.
>
> Ok, my only point is, sometimes we do cleanups without discussing the
> possible implications very much.  I don't have any concrete objections
> to this specific clean-up, I just think it's good that we understand,
> as a community, when a seemingly benign cleanup could potentially
> affect functional capability of the system.

Sure, agreed. And these kinds of discussions hopefully help with
disseminating knowledge of the system.

frank