[RFC] strawman explict object-tracking API

[Martin Pool]

On 4/17/07, Robert Collins <robertc at robertcollins.net> wrote:
> >   reuse(args, kwargs):
> >      Try to reuse this object instead of constructing a new object
> > with the given constructor arguments.  This can return self, or a new
> > object based on self, or None if it's not possible.

I think this can be a bit like Registry: there is a common base class
and then some specialization for the various things that are
respectively registered or reused.  At least having it there tells
people they can expect them to behave the same way.

Note that Reusable can just be a duck interface.

> I'm not sure we need this. For Transports cloning is an existing
> interface. For repositories and branches just being at the url we want
> to open a branch at (nb - *at*, not at-or-above) is sufficient. Having
> an interface on the object is useful if we want to delegate behaviour to
> the object. Possibly you are suggesting that we can have a completely
> abstract interface to achieve reuse by having the test for 'can this be
> reused in this situation' delegated to the object. We probably can, but

ok.

> I don't like having to use *args, **kwargs - they are pernicious
> constructs in general, so at that moment I'd rather have multiple
> 'Reuser' objects with non-keyward based methods to get reuse, than one
> 'Reuser' class whose reuse take kwards.

I would imagine having the specific ReusePool or the method that uses
it provide a non varargs interface.

> > ReusePool:
> >
> >   create_or_reuse(args, kwargs):
> >      Used in place of constructing a new object with the given
> > parameters.
> >      Either return an appropriate reused object, or construct and
> > remember a new one.
> >
> >   register(obj):
> >      Remember an object as a possible source of reuse.
> >
> >   deregister(obj):
> >      ...
> >
> > Maybe there's an existing pattern name for this?
>
> I don't really like the ReusePool approach at this point. I considered
> something like it when putting my proposal forward. What I dont like
> about it is that it we'll need a bunch of these - one for BzrDir's, one
> for Repositories, one for Branches etc - I think that pushing this into
> the Branch, Repository, BzrDir respective open methods is cleaner. But
> perhaps a prototype will show this wrong?

Well maybe I'd need to see the code.  But it seems to me there is a
common concept of "is there anything I can reuse" that can be split
out, even though the details of what is reusable vary, rather than
repeating it through every factory method that does this.

-- 
Martin