Why does MessageSet subclass Browser?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does MessageSet subclass Browser?

Frank Shearar
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

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Chris Muller-3
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.

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,
  Chris


On Sun, Mar 6, 2011 at 3:53 PM, Frank Shearar
<[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Frank Shearar
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
> <[hidden email]>  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
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Tony Garnock-Jones-3
On 2011-03-07 5:48 PM, Frank Shearar wrote:
> 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).

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?

Tony

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Chris Muller-3
In reply to this post by Frank Shearar
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Chris Muller-3
On Mon, Mar 7, 2011 at 5:16 PM, Chris Muller <[hidden email]> 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.

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Colin Putney-3
In reply to this post by Tony Garnock-Jones-3
On Mon, Mar 7, 2011 at 2:52 PM, Tony Garnock-Jones <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Frank Shearar
In reply to this post by Chris Muller-3
On 2011/03/08 01:47, Chris Muller wrote:

> On Mon, Mar 7, 2011 at 5:16 PM, Chris Muller<[hidden email]>  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

Reply | Threaded
Open this post in threaded view
|

Re: Why does MessageSet subclass Browser?

Tony Garnock-Jones-3
In reply to this post by Colin Putney-3
On 2011-03-07 10:31 PM, Colin Putney wrote:
> That's exactly the approach taken by OmniBrowser.

Ah! I must have been searching under the streetlamps for my keys :-)

Thanks for the pointer.

Tony