ui factory - what should it do?

[Martin Pool]

On 24 Feb 2006, Robert Collins <robertc at robertcollins.net> wrote:
> On Fri, 2006-02-24 at 10:53 +1100, Martin Pool wrote:
> 
> > > Because if I were to convert fetcher to have a do-it method, I'd put the
> > > entire body of the __init__ method there.  And then I'd have to restore
> > > the members to safe values afterward, so no unsafe member functions
> > > could be called.
> > > 
> > > There is definitely a need for an idiom represent a procedure with
> > > multiple phases and shared data, where that shared data becomes obsolete
> > > at the end of the procedure, and this way didn't seem so bad, on reflection.
> > 
> > I don't really mind it, and agree with your point about the member
> > fields.  I think I've created at least one such class myself.
> > 
> > My main thing was that we should perhaps make classes like this
> > consistent with each other.  If no one dislikes doing it in __init__ we
> > can use that.
> 
> I really don't like putting 'do it' logic in __init__. Several reasons.
> 
> If you want to pass in a parameterised worker object, you can't do that
> with __init__ doing the work, instead you need to pass in a customised
> factory function. Its more flexible therefore to construct objects that
> can perform the task and then ask them to perform it. Most of the time
> you won't need that, but when you do its nice not to have to jump
> through extra hoops.

So perhaps such classes should have a small or empty __init__, and
parameters should be given to the do-it method.  Commit() is a bit like
this.  (However it is also something that might be happier as just a set
of functions.)

> I'm also not happy with using __call__ in case anyone is wondering, as
> it can be extremely confusing to have a callable instance of an object.

Yes I think that should be reserved for very special cases where you
really need to simulate a callable, not just as sugar.

> W.r.t. the reuse of member variables: We're not talking about having
> these objects around for indefinite periods : I don't think coding every
> one of them for serial-calls is sensible, I'd ignore the issue until you
> have a use case for reusing an instance of one of these objects.

I think the discomfort there comes from having references in a
long-lived object that are only meaningful for the duration of a single
call.  (It sounds like I'm talking about gc but I'm thinking of the
burden on the developer not on the system.)  If the class is hidden
from most callers behind a function it's less of a problem but 

-- 
Martin