Re: The Trunk: Tools-eem.471.mcz

This would seem to change the capability that a browser can have the
same message in the list more than once.

Is this to support some functionality?  Or just a "clean up"?

On Fri, Jun 14, 2013 at 3:55 PM,  <[hidden email]> wrote:

On 22 June 2013 00:37, Chris Muller <[hidden email]> 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...

> 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.

I can't recall offhand what I did in the MessageSet group of browsers,
but I'm pretty sure they no longer use indices either.

frank

On Sat, Jun 22, 2013 at 3:42 AM, Frank Shearar <[hidden email]> wrote:
> On 22 June 2013 00:37, Chris Muller <[hidden email]> 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.
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".

>> 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.

On 22 June 2013 19:48, Chris Muller <[hidden email]> wrote:
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.

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

frank