On 2008-06-05 13:03:55 +0100, Catalin Marinas wrote:
> 2008/6/5 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > 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!
> >> + @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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
