[squeak-dev] The Trunk: SUnitGUI-fbs.57.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Jan 9 17:17:38 UTC 2014


I would say ToolBuilder-Morphic should depend on Morphic, not the other way
around.
So why not putting PluggableSystemWindowWithLabelButton in
ToolBuilder-Morphic?
Isn't it a pluggable extension for Morphic that should be used only thru
ToolBuilder?
Otherwise, we can consider that as a bad usage of inheritance, or a case of
Traits...


2014/1/9 Frank Shearar <frank.shearar at gmail.com>

> On 9 January 2014 14:27, Frank Shearar <frank.shearar at gmail.com> wrote:
> > On 9 January 2014 13:34, Colin Putney <colin at wiresong.com> wrote:
> >>
> >>
> >>
> >> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <frank.shearar at gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> It does for SUnit what older commits did for MVC and Morphic: moves
> >>> the UI-framework-specific code to that particular UI framework, so
> >>> that the core of ToolBuilder remains UI agnostic.
> >>>
> >>> The problem with shrinking that you refer to is, presumable, that
> >>> SUnitToolBuilderTests superclass == AnObsoleteToolBuilderTests? I'd
> >>> noticed that, and asked on the list how I might fix that. If you can
> >>> suggest an action I can take to remedy the problem, I'm all ears.
> >>
> >>
> >> No, the problem with shrinking is that I want to remove SUnitToolBuilder
> >> without removing TestRunner.
> >>
> >> TestRunner provides a GUI for running tests. SUnitToolBuilder provides
> >> infrastructure for testing a GUI. They *sound* similar, but really
> they're
> >> completely different, and should be in separate packages.
> >
> > Yes, they are different.
> >
> >> On the other hand, the ToolBuilder packages were already separate from
> each
> >> other. Admittedly, if you don't have MVC in the image, you probably
> don't
> >> want ToolBuilder-MVC either, but that's not a reason to tie them
> together;
> >> it's reasonable to want MVC only and not use ToolBuilder at all. It
> seems
> >> that these changes have introduced coupling to what was already a nicely
> >> modularized group of packages.
> >>
> >> I'm sorry I didn't notice this when you first brought it up—I was busy
> with
> >> dirty-world stuff in May and not paying much attention to the Internet.
> I
> >> think the right thing to do is just revert these changes.
> >
> > I suspect that the bug might stem from me looking at system
> > categories, not at packages. ToolBuilder is one of the packages (only
> > it and HelpSystem, in fact) that do the Right Thing sub-package-wise.
> >
> > You're right. I'll revert the changes.
>
> Undoing these changes, I think I realise why I did it. Morphic depends
> on ToolBuilder-Morphic, and I tried to break that dependency by
> folding TB-M into Morphic. Once that was done, what's good for one
> framework should be good for the others. Only of course while Morphic
> shouldn't depend on TB-M, folding TB-M into Morphic means that Morphic
> still depends on TB, which it shouldn't. (Because using TB was
> supposed to be optional. It's TOOLBuilder, not GenericUIBuilder.
>
> So Morphic still depends on ToolBuilder-Morphic, because
> PluggableSystemWindowWithLabelButton subclasses PluggableSystemWindow,
> and because UserDialogBoxMorph uses PluggableButtonMorphPlus.
>
> frank
>
> >> Colin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140109/38b77767/attachment.htm


More information about the Squeak-dev mailing list