On 9 August 2013 13:08, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 9 August 2013 12:56, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>> On 2013-08-09, at 09:56, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>>> One of the System -> Tools dependencies is from Preferences class >>
>>> #browseThemes where there is a line
>>>
>>>    aBrowser := Browser new setClass: Preferences selector: #outOfTheBox.
>>>
>>> We have a SystemBrowser AppRegistry, so we could change this to
>>>
>>>    aBrowser := SystemBrowser default new setClass: Preferences
>>> selector: #outOfTheBox.
>>>
>>> But SystemBrowser doesn't properly describe the protocols a class
>>> ought to support to be a suitable system browser. So if someone uses a
>>> non-Browser SystemBrowser, they might get a nasty surprise.
>>>
>>> One possible solution is to add a #setClass:selector: (or rather,
>>> #browseClass:selector:) method to SystemBrowser. That would make the
>>> protocol a bit more explicit.
>>
>>
>> I'd prefer a class-side protocol similar to these:
>>
>> Browser newOnClass: Preferences class selector: #outOfTheBox.
>> Browser fullOnClass: Preferences class selector: #outOfTheBox.
>
> I just realised I hadn't said "class side" when I'd meant to. So in
> the above call site we'd have
>
>     aBrowser := SystemBrowser openOnClass: Preferences selector: #outOfTheBox
>
> (I prefer "open" to "new" because I don't care about getting a new
> browser so much as I care about browsing a particular method on a
> particular class.)
>
>> We have SystemBrowser class>>defaultOpenBrowser which is almost unused, renaming that to "openBrowser" and adding a method to open a full browser on a particular method would be nice.
>
> Sounds like a plan! (Specifically: "adding class-side methods to
> SystemBrowser so that alternative browsers have a clear protocol
> against which to work")

Actually, I entirely failed to notice that SystemBrowser is itself in
Tools, so removing this (part of the) dependency will require a
rethink.

frank

>> - Bert -