Re: [StGIT PATCH 3/5] Create a git.Branch class as ancestor of stack.Stack

From: Karl Hasselström <kha@treskal.com>
Date: Jun 5, 2008, 13:04 UTC
Message-ID: <20080605130415.GB28995@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0806050503x40191104ye332d6a8435811a5@mail.gmail.com>

On 2008-06-05 13:03:55 +0100, Catalin Marinas wrote:

Show 15 quoted lines

> 2008/6/5 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-06-04 22:13:35 +0100, Catalin Marinas wrote:
> >
> > > +    def __init__(self, repository, name):
> > > +        self._repository = repository
> > > +        self._name = name
> >
> > Using double leading underscores will give you a class-local name.
> > Why just one?
>
> Just a convention: double underscore - private, simple underscore -
> protected (using C++ or Java naming). The _repository or _name are
> meant to be made available to a derived class (stack.Stack in our
> case), though we have the corresponding public properties already.

OK. Then I'd argue that these two should be private since there's no particular reason for them to be just protected, but I think I've done enough nitpicking for one day already!

Show 13 quoted lines

> >> +    @classmethod
> >> +    def create(cls, repository, name, create_at = None):
> >
> > Minor nit: in case of things that are clearly "owned" by other
> > things (git objects are owned by a git repository, for example),
> > I've tried to put the creation function in the owner, not the
> > owned. I'm not insisting, though.
>
> As I see these things, the git.Repository and the derived
> stack.Repository are indeed object factories but they are mainly
> responsible for creating/returning a new Python object and passing
> some arguments to the class' __init__. The Repository object doesn't
> need to know more than the name as the rest is handled by __init__.

Yes. This is exactly how it works e.g. when a Repository creates Blob, Tree, or Commit objects.

> The same goes for the "create" function, the repository shouldn't
> need to know the directory or files structure that a Stack or Branch
> are using. I think we get a clearer separation this way.

Yes, you're right. Knowledge of internals belong in the class itself.

We'll have to be watchful against attempts to create objects other than via the officially designated factories, though. Python doesn't really have any mechanisms that help us here.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle