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

On Mon, Mar 7, 2011 at 2:52 PM, Tony Garnock-Jones tonyg@ccs.neu.edu wrote:

I've previously tried to figure out whether it'd be possible to fake it in this area, defining some classes SystemCategory, MessageCategory as wrappers that know how to get at the information they need that is stored elsewhere. I never managed to figure out a way of doing it though. Would something like that be a worthwhile half-step on the way toward having proper reified Categories and so on?

That's exactly the approach taken by OmniBrowser.

Colin

super/subclass. A MessageSet does less things than a Browser.

Hmm, no it doesn't. It sounds like you're thinking of a "Browser" as a PackagePane browser. In fact, a PackagePaneBrowser is-a Browser just as a HierarchyBrowser is-a Browser just as a MessageSet is-a Browser. Hope that helps.

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:"

I appreciate wanting to use verbs / terse-English, but I think for the ToolBuilder API, it is better to stick to uniformity between the getter and setter; #selectedSystemCategory and #selectedSystemCategory:.

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.

With the PackagePane browser our categories are just Strings anyway; I wasn't referring to those lists. I'm talking about the lists which render Objects other than Strings, like the various message-lists. OO user-interfaces should present original MethodReference objects directly, not Stringified copies.

Making Stringy copies is a "relational", not OO-paradigm, because then you have to always "look up" the real object based on the selected String, etc. which is more complex, more garbage, etc.

- Chris

On 2011/03/08 01:47, Chris Muller wrote:

On Mon, Mar 7, 2011 at 5:16 PM, Chris Mullerasqueaker@gmail.com wrote:

...

...

super/subclass. A MessageSet does less things than a Browser.

Hmm, no it doesn't. It sounds like you're thinking of a "Browser" as a PackagePane browser. In fact, a PackagePaneBrowser is-a Browser just as a HierarchyBrowser is-a Browser just as a MessageSet is-a Browser. Hope that helps.

About this, I realize now you were referring to the actual implementation, not the semantics. Yes, Browser seems to have too much in it.

Yes, that's exactly it. I'm more interested in the story behind the choice to subclass Browser rather than pull out the common bit into, say, BaseBrowser, and subclass off that.

That particular bit of work's for another day though :)

frank