[squeak-dev] Re: The Trunk: ToolBuilder-Kernel-dtl.34.mcz

Andreas Raab andreas.raab at gmx.de
Tue May 4 03:22:22 UTC 2010


On 5/3/2010 5:27 PM, David T. Lewis wrote:
> I did not actually measure it, so I'm not sure if it matters with respect
> to performance. That said, the method that figures out what flavor of
> UIManager to instantiate is a bit complex, so it may have some value.

Not really. When you're about to ask the user for input you must include 
the user response times so you're not going to rely on calling any of 
the methods 1000/sec :-)

> But the real reason I did it is that the UIManager was clearly designed
> with the intent of maintaining a reference to single instance while any
> given user interface is in effect. This was supported by referring to
> the default UIManager through a class variable. I presume the intent
> was to update this variable whenever the type of user interface changed
> (i.e. enter a different kind of project), although this had not yet been
> implemented in our trunk image.
>
> That approach made good sense when maintaining UIManager as a separate
> package, but it did require that the default UIManager be updated
> when changing projects, which actually ends up being a bit complicated
> (and that may be why it never got implemented). But the UIManager
> is conceptually related to Project, in the sense that a project has
> a kind of user interface, and the UIManager implements the appropriate
> UI requests for that kind of project. So it turns out to be simpler to
> just give the Project a UIManager, and not bother with trying to keep
> the value of "UIManager default" up to date when switching projects.

Indeed. Your reasoning on the historical aspects is correct. I was 
trying to avoid external dependencies as much as possible. I actually 
still think that's somewhat worthwhile since it matters so little 
performance-wise. But I don't feel strongly about it.

Cheers,
   - Andreas

> And last but not least, it made the class comment simpler ;-)
>
> Dave
>
> On Mon, May 03, 2010 at 10:24:52AM -0500, Chris Muller wrote:
>> Since UIManager does not have any state, will this matter?  YAGNI?
>>
>> On Sun, May 2, 2010 at 5:19 PM,<commits at source.squeak.org>  wrote:
>>> David T. Lewis uploaded a new version of ToolBuilder-Kernel to project The Trunk:
>>> http://source.squeak.org/trunk/ToolBuilder-Kernel-dtl.34.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: ToolBuilder-Kernel-dtl.34
>>> Author: dtl
>>> Time: 2 May 2010, 6:15:49.448 pm
>>> UUID: d9bb885a-17d0-45ae-b93e-04cdf4e05a9f
>>> Ancestors: ToolBuilder-Kernel-MAD.33
>>>
>>> Associate an instance of UIManager with each project, such that UIManager current refers to an appropriate instance for that type of project. Remove incomplete implementation of caching the current UIManager instance in class UIManager.
>>>
>>> Update class comment for UIManager.
>>>
>>> =============== Diff against ToolBuilder-Kernel-MAD.33 ===============
>
>




More information about the Squeak-dev mailing list