System -> Tools via Preferences

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

System -> Tools via Preferences

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

Thoughts?

frank

Reply | Threaded
Open this post in threaded view
|

Re: System -> Tools via Preferences

Bert Freudenberg

On 2013-08-09, at 09:56, Frank Shearar <[hidden email]> 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.

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.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: System -> Tools via Preferences

Frank Shearar-3
On 9 August 2013 12:56, Bert Freudenberg <[hidden email]> wrote:

>
> On 2013-08-09, at 09:56, Frank Shearar <[hidden email]> 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")

frank

> - Bert -

Reply | Threaded
Open this post in threaded view
|

Re: System -> Tools via Preferences

Frank Shearar-3
On 9 August 2013 13:08, Frank Shearar <[hidden email]> wrote:

> On 9 August 2013 12:56, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 2013-08-09, at 09:56, Frank Shearar <[hidden email]> 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 -