On 13 May 2013 15:33, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, May 13, 2013 at 01:00:40PM +0100, Frank Shearar wrote:
>> On 13 May 2013 12:57, Frank Shearar <frank.shearar at gmail.com> wrote:
>> > On 13 May 2013 12:48, David T. Lewis <lewis at mail.msen.com> wrote:
>> >> On Mon, May 13, 2013 at 12:12:32PM +0100, Frank Shearar wrote:
>> >>> This guy's basic structure is
>> >>>
>> >>> Smalltalk isMorphic
>> >>>     ifFalse: ["do something"]
>> >>>     ifTrue: [ToolSet browseMessageNames: aString]
>> >>>
>> >>> It seems to me that this should simply be
>> >>>
>> >>>     ToolSet browseMessageNames: aString
>> >>>
>> >>> where a non-Morphic ToolSet does the "do something" block.
>> >>>
>> >>> Right?
>> >>
>> >> Probably yes. I can't look at it right now, but in general things like this
>> >> are being vectored through either Project or ToolBuilder, and maybe ToolSet
>> >> references should work the same way. When you change it, use an MVC project
>> >> to verify that it works as expected in the non-Morphic case(s).
>> >
>> > Which would be the second time I've run into the desire for this:
>> >
>> > ToolSet use: mySpecialToolSet during: [
>> >   "MySpecialToolSet test"
>> > ]
>> >
>> > I _could_ use #setUp/#tearDown, but that's not quite the same thing:
>> > errors in the test should reference MySpecialToolSet but errors in the
>> > #setUp/#tearDown should reference the "system" ToolSet (in other words
>> > the current StandardToolSet).
>>
>> I should add that if/when I make the above change, I'd just fold the
>> ifFalse: code into whatever MVC uses for its ToolSet... which leads to
>> the question "does MVC even _have_ a ToolSet?". If it doesn't, the
>> thing to do is to make one, and make it a subclass of StandardToolSet.
>> We'd also need some initialization logic to set the ToolSet for MVC
>> folks.
>
> In general you want to replace the if/then/else stuff by dispatching
> to the appropriate kind of project or tool builder. But you also want
> to keep the number of interfaces to a minimum so people do not need
> to implement lots of interfaces for every possible kind of project or
> user interface.
>
> I don't see much use of ToolSet in the image. Is this a fundamental thing
> that needs further implementation work, or is it just a half-finished
> proof of concept that never got traction?

ToolSet's normally set to StandardToolSet. If it isn't a fundamental
thing, it ought to be: it does for application registration what
ToolBuilder does for building UIs.

Regarding usage, I see 46 references to ToolSet in trunk, compared to
29 + 12 for Browser + MessageSet. Not exactly an apples-to-apples
comparison, because there are Browser references in the tests, while
ToolSet wraps up (at the moment) access to Browser, MessageSet, the
Inspectors/Explorers and code completion.

More anecdotally, squeak-ci's CommandLineToolSet has allowed Dale
Henrich and I to actually debug our CI work. I think it's safe to say
that Metacello still runs on Squeak only because of the
CommandLineToolSet, which would be useless without ToolSet.

frank

> Dave
>
>
>>
>> Er, actually that's not entirely necessary. _Right now_ all that's
>> needed is to push the code from SystemNavigation into StandardToolSet.
>> STS can then be Morphic+MVC or just Morphic as desired.
>>
>> frank
>>
>> >> Dave
>