On Jan 31, 2008, at 5:17 PM, Eric Williams wrote:
>
> On Jan 31, 2008, at 1:39 PM, Lars Jensen wrote:
>
>>> True enough - but this seems like extra work to me. Why not just
>>> keep
>>> track of everything as you create it? That way you'll always know
>>> what's going on instead of having to repeatedly cycle through all
>>> the
>>> windows to find the one you want.
>>
>> "Keeping track of" is another way of saying "caching information
>> about". Caching is an optimization. Premature optimization is bad
>> because it increases complexity and therefore risk of bugs.
>> Therefore,
>> unless you have a need to keep track of something (e.g. for
>> performance reasons), it's generally better practice to ask the
>> system
>> for current information.
>>
>> Put another way: always ask the system, and if the system needs to
>> cache the info, it can. That way, the benefit of caching is spread
>> while the complexity remains contained.
>
> Yikes! So I shouldn't keep track of document windows when they are
> created? It's not as if a document window is going spontaneously
> materialize behind my application's back - document windows only come
> into existence when my app creates or opens a document. And when I go
> to shut down my application, I can cycle through each document object
> and tell it to close its window (instead of cycling through all the
> windows in memory, figuring out if they are document windows, and
> sending them a close command). This seems to me to be the very
> underpinnings of object orientation.
>
> I agree that premature optimization can be bad, but when you are
> dealing with a reference-counting garbage collector, I personally
> think it's a good idea to know where your objects are. That doesn't
> seem like an optimization to me, merely good accounting. On the other
> hand, if you are dealing with a resource that is shared amongst
> multiple processes - for example, USB-based serial ports that can be
> easily unplugged- it is always good practice to reflect the current
> state of the system.
I don't see how reference counting matters, except insofar as the
existence of more object references means more opportunity for
circular references and that sort of thing.
If you have, say, a DocumentWindow class, you could write a function
like the following.
Function DocumentWindowList() as DocumentWindow()
dim theList() as DocumentWindow
for i as Integer = 0 to WindowCount - 1
dim w as Window = Window(i)
if w isA DocumentWindow then
theList.Append DocumentWindow(w)
end if
next
return theList
End Function
Now you've isolated the search for DocumentWindows, and you can call
this function when it's time to quit. You don't keep any additional
state that can turn rancid or attract bugs.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|