On 2011/03/07 21:18, Chris Muller wrote:
> Hi Frank, I don't know if I have a definitive answer to your question
> other than; a MessageSet is a "Browser" of messages (err, methods),
> and it probably inherits quite a bit of behavior there.

Yes, you get most of your stuff For Free. It's just that I'd expect, in 
some sort've purist sense, to see the common behaviour between Browser 
and MessageSet in a common superclass, making them siblings rather than 
super/subclass. A MessageSet does less things than a Browser.

> I'm glad you're doing this improvement on the browsers; I hope you are
> going "all the way" and letting each of the lists be populated with
> first-class objects, like MethodReferences instead of Strings.  I
> know, in some cases where formatting or emphasis is required, that
> won't be possible, but in most cases it should be.
>
> This is now much easier because the list widgets now send
> #asStringOrText to each rendered objects at low-levels (e.g.,
> drawing), rather than assuming they are already Strings or Texts way
> up in the domain level.

Thanks for the encouragement, Chris!

Indeed, my basic strategy is to store the Symbol or String name of the 
viewed thing rather than the index. So

| b |
b := Browser new.
b selectedSystemCategory: 'Tools-Browser'. "I want to change this to 
#selectSystemCategory: - better reading, and more uniform with the 
existing style, like #selectClass:"
b selectClass: b class.

The methods that ToolBuilder needs - 
#systemCategoryListIndex/#systemCategoryListIndex: and similar pairs - 
then wrap around the currently selected item, for instance like so:

     self selectSystemCategory: (self systemCategoryList at: anInteger 
ifAbsent: [ nil ])

I think it's wiser to use strings/symbols rather than actual entities 
because sometimes we don't have reified entities(system categories, 
message categories). Also, Browser works entirely on lists of names at 
the moment, rather than lists of objects (classes, methods) with names.

I've wiped out selectSystemCategoryListIndex, and am working on 
classListIndex. That's a bit of a trickier case, because sometimes an 
innocuous-looking change ends up breaking badly. The key to self-brain 
surgery is writing tests as you work, and regular backups!

frank

>
> Thanks,
>    Chris
>
>
> On Sun, Mar 6, 2011 at 3:53 PM, Frank Shearar
> <frank.shearar at angband.za.org>  wrote:
>> In removing Browser's use of indices in favour of using symbols to track
>> what a Browser's currently browsing, I found I couldn't add an instvar
>> called selectedClass. TimeProfileBrowser uses it.
>>
>> TimeProfileBrowser subclasses MessageSet, which we use to model senders-of
>> and implementors-of. But why does MessageSet - a model to view a collection
>> of methods - subclass Browser, a model used to explore Smalltalk code at
>> large?
>>
>> I'm thinking "historical accident, because it was cheap/expedient to
>> repurpose some chunks of Browser and simply ignore the rest", but I'm
>> curious if my guess is right or not.
>>
>> frank
>>
>>
>
>