From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: [StGIT PATCH 3/5] Create a git.Branch class as ancestor of stack.Stack
Date: Fri, 6 Jun 2008 09:44:37 +0100 [thread overview]
Message-ID: <b0943d9e0806060144x48176566m277ba2969087b91e@mail.gmail.com> (raw)
In-Reply-To: <20080605130415.GB28995@diana.vm.bytemark.co.uk>
2008/6/5 Karl Hasselström <kha@treskal.com>:
> On 2008-06-05 13:03:55 +0100, Catalin Marinas wrote:
>> 2008/6/5 Karl Hasselström <kha@treskal.com>:
>> 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.
Doesn't need to be enforced. The Stack and Branch objects can be
initialised by themselves provided that the repository is passed as
argument at construction. The factory is more for convenience, passing
the repository to the newly created object.
If you really want enforcing this, it can probably be done by hacking
__new__ and __init__.
--
Catalin
next prev parent reply other threads:[~2008-06-06 8:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-04 21:13 [StGIT PATCH 0/5] Various updates to the new infrastructure Catalin Marinas
2008-06-04 21:13 ` [StGIT PATCH 1/5] Allow stack.patchorder.all to return hidden patches Catalin Marinas
2008-06-05 6:41 ` Karl Hasselström
2008-06-05 11:46 ` Catalin Marinas
2008-06-04 21:13 ` [StGIT PATCH 2/5] Rename Repository.head to Repository.head_ref Catalin Marinas
2008-06-05 6:46 ` Karl Hasselström
2008-06-05 11:49 ` Catalin Marinas
2008-06-05 11:58 ` Karl Hasselström
2008-06-05 12:06 ` Catalin Marinas
2008-06-05 12:46 ` Karl Hasselström
2008-06-04 21:13 ` [StGIT PATCH 3/5] Create a git.Branch class as ancestor of stack.Stack Catalin Marinas
2008-06-05 7:01 ` Karl Hasselström
2008-06-05 12:03 ` Catalin Marinas
2008-06-05 13:04 ` Karl Hasselström
2008-06-06 8:44 ` Catalin Marinas [this message]
2008-06-07 9:06 ` Karl Hasselström
2008-06-08 22:16 ` Catalin Marinas
2008-06-09 0:07 ` David Aguilar
2008-06-09 0:46 ` Sverre Rabbelier
2008-06-09 7:07 ` Karl Hasselström
2008-06-04 21:13 ` [StGIT PATCH 4/5] Add stack creation and initialisation support to lib.Stack Catalin Marinas
2008-06-05 7:28 ` Karl Hasselström
2008-06-05 12:42 ` Catalin Marinas
2008-06-07 8:59 ` Karl Hasselström
2008-06-04 21:13 ` [StGIT PATCH 5/5] Add stack creation and deletion support to the new infrastructure Catalin Marinas
2008-06-05 7:34 ` Karl Hasselström
2008-06-05 9:43 ` Catalin Marinas
2008-06-05 7:38 ` [StGIT PATCH 0/5] Various updates " Karl Hasselström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0943d9e0806060144x48176566m277ba2969087b91e@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=kha@treskal.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).