--On Sunday, March 26, 2006 9:18 AM -1000 Hongbing Kou
<[EMAIL PROTECTED]> wrote:
As best as I can remember some dailyproject objects have reference to
workspace because the metric values are computed on the fly with
workspace data. With the changes you have made on DailyProjectData it may
not be the case anymore. Just be careful when you decide to take this
method out.
OK, I did some review of the code, and here's my current understanding:
(a) The DailyProjectData instances need to be aware of changes to
WorkspaceRoots. When a WorkspaceRoot is changed, we need to be able to
flush the cache of affected DailyProjectData instances and recompute them.
(b) The way we accomplish (a) is by making the DailyProjectDataCache a
ProjectListener, so its projectChanged callback method is invoked whenever
a Project is changed. One of the events that indicate a change to a Project
is a change to the WorkspaceRoots.
(c) So, it turns out that while we _do_ need the DailyProjectData instances
to react to changes in the Workspaces, we _don't_ need the
hasWorkspaceData() method to accomplish this. Instead, we are using the
(better) approach of de-caching instances whenever their associated Project
changes, of which one situation is when their Workspaces change.
If you think about it, it doesn't actually matter if the DailyProjectData
instance _currently_ holds Workspace instances or not. What matters is if
the metrics that it caches were based upon Workspaces (which they always
are), and if the set of Workspaces has changed since the time at which the
metrics were computed (which would mean the metrics need to be recomputed).
Thus, clearing the cache of DailyProjectData instances whenever the Project
definition changes, regardless of whether the instance holds Workspaces or
not, is the desired behavior.
Whew. This is a very long way of saying that Cedric can, indeed, delete the
hasWorkspaceData() method, both from the DailyProjectData superclass and
any subclasses that might override it. It would be good to do a full
recompile of the hackySdt_* subsystem, and any hackyApp modules that
contain DailyProjectData definitions, to make sure that no one has written
code that depends upon this method.
I have the feeling that I originally defined the hasWorkspaceData() method
in the superclass early on in the design of the cache, then forgot to take
it out when Hongbing and I figured out that making it a ProjectListener was
a more effective solution to the problem.
Cheers,
Philip
