Re: [sabayon] apply, start_monitoring, delegate construction and initial state

[John Dennis <jdennis redhat com>]

On Wed, 2005-03-23 at 09:34 +0000, Mark McLoughlin wrote:
> On Tue, 2005-03-22 at 18:41 -0500, John Dennis wrote:
> > First a question:
> > 
> > When apply is called in a source/delegate module it is a separate
> > instance from when monitoring is invoked, right? This will be key in a
> > moment.
> 
> 	Well, they're completely different processes ... i.e. apply() is
> invoked from sabayon-apply and monitoring is only used in
> sabayon-monitor.

Right, and that is very significant, they are two very different
operations.

> > How does a delegate create it's initial state? In other words before
> > monitoring begins it might need to capture the state of the files its
> > going to monitor (so it can tell what's different in those files). When
> > can the delegate create this initial state? Delegates don't get called
> > for start_monitoring, which I think is the right moment. The delegate
> > constructor is not the right place, construction is not limited to
> > monitoring nor is it necessarily at the right moment. I considered
> > creating the initial state after being invoked to apply, thats not a bad
> > moment, except (see first question) I don't think the apply and the
> > monitoring are using the same objects, they're invoked indpendently
> > (right?)
> > 
> > So is the right answer that we need to add start_monitoring as a
> > delegate member and invoke it so delegates can initialize in preparation
> > for monitoring?
> 
> 	Well, you're going to need the initial state when you're applying too,
> right? So, I don't see what's wrong with doing it in the constructor ..

FYI, here is why I think the constructor is not the right place.

* Building a data structure of the current state in order to perform
"before" and "after" comparisions to extract differences is only useful
in the monitoring case, it would be a pointless operation in the apply
case, it would slow apply down, and when the apply operation completed
the data would be discarded without ever have been referenced (or it
might simply be overwritten during apply).

* Constructors should create objects in a default state. Once an object
is instantiated it can be asked to perform operations via its methods,
such as opening and reading files. At this point the purpose of the
object is known by its creator and the correct operations can be invoked
by its creator, something the object during its creation can't know. I
guess this might just be an OO philosophy thing ;-)

* The presences or absense of files at the time the constructor is
called in the monitoring vs. apply scenario have different meanings and
you want to do different things. The constructor would have to be aware
of the context the object of was being created in (monitoring vs.
apply). Not only would it be awkward to teach the constructor the
different contexts it could be created in, it also feels like bad OO
software practice, better to use its methods to tell it what to do.

> 
> 	But if you want to add start_monitoring() to SourceDelegate, I've no
> problem with that.

Cool, that's what I'm going to do. I think its cleaner and more
efficient. Mostly I was just checking to make sure there wasn't a reason
why a delegate does not share the start_monitoring method with a source
object that I might have overlooked.
-- 
John Dennis <jdennis redhat com>