Re: The Trunk: SUnitGUI-fbs.57.mcz

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

Re: The Trunk: SUnitGUI-fbs.57.mcz

Colin Putney-3



On Fri, May 31, 2013 at 10:03 AM, <[hidden email]> wrote:
Frank Shearar uploaded a new version of SUnitGUI to project The Trunk:
http://source.squeak.org/trunk/SUnitGUI-fbs.57.mcz

==================== Summary ====================

Name: SUnitGUI-fbs.57
Author: fbs
Time: 31 May 2013, 4:03:07.92 pm
UUID: b836135e-01ed-4f6e-b671-36c56a5fa89a
Ancestors: SUnitGUI-eem.56

Move ToolBuilder-SUnit to SUnitGUI-ToolBuilder.


One of the issues I ran into with shrinking goes back to this commit, which makes no sense to me. Frank, can you remember the reasons for this?

Colin
 



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Frank Shearar-3
On 9 January 2014 00:26, Colin Putney <[hidden email]> wrote:

>
>
>
> On Fri, May 31, 2013 at 10:03 AM, <[hidden email]> wrote:
>>
>> Frank Shearar uploaded a new version of SUnitGUI to project The Trunk:
>> http://source.squeak.org/trunk/SUnitGUI-fbs.57.mcz
>>
>> ==================== Summary ====================
>>
>> Name: SUnitGUI-fbs.57
>> Author: fbs
>> Time: 31 May 2013, 4:03:07.92 pm
>> UUID: b836135e-01ed-4f6e-b671-36c56a5fa89a
>> Ancestors: SUnitGUI-eem.56
>>
>> Move ToolBuilder-SUnit to SUnitGUI-ToolBuilder.
>
>
>
> One of the issues I ran into with shrinking goes back to this commit, which
> makes no sense to me. Frank, can you remember the reasons for this?

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.

frank

> Colin

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Colin Putney-3



On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]> 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. 

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. 

Colin


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Frank Shearar-3
On 9 January 2014 13:34, Colin Putney <[hidden email]> wrote:

>
>
>
> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]>
> 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.

> Colin

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Frank Shearar-3
On 9 January 2014 14:27, Frank Shearar <[hidden email]> wrote:

> On 9 January 2014 13:34, Colin Putney <[hidden email]> wrote:
>>
>>
>>
>> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Colin Putney-3



On Thu, Jan 9, 2014 at 11:13 AM, Frank Shearar <[hidden email]> wrote:

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.

Ah, that makes sense. 

So we need to figure out how to break that connection. Perhaps we'd get rid of all the Plus morphs and fold that functionality into either Morphic (PluggableFooMorph) or ToolBuilder (extensions to PluggableFooMorph) depending on whether its generally useful.  

Colin


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Nicolas Cellier
In reply to this post by Frank Shearar-3
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 <[hidden email]>
On 9 January 2014 14:27, Frank Shearar <[hidden email]> wrote:
> On 9 January 2014 13:34, Colin Putney <[hidden email]> wrote:
>>
>>
>>
>> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]>
>> 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




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SUnitGUI-fbs.57.mcz

Karl Ramberg
+1

Cheers,
Karl


On Thu, Jan 9, 2014 at 6:17 PM, Nicolas Cellier <[hidden email]> wrote:
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 <[hidden email]>
On 9 January 2014 14:27, Frank Shearar <[hidden email]> wrote:
> On 9 January 2014 13:34, Colin Putney <[hidden email]> wrote:
>>
>>
>>
>> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]>
>> 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