Re: Why does this not exist?
- From: Philip Van Hoof <spam pvanhoof be>
- To: Sergio Villar Senin <svillar igalia com>
- Cc: tinymail-devel-list gnome org
- Subject: Re: Why does this not exist?
- Date: Mon, 12 Feb 2007 14:45:22 +0100
On Mon, 2007-02-12 at 13:17 +0100, Sergio Villar Senin wrote:
> Philip Van Hoof wrote:
> > Would that return the parent of the folder?
>
> Indeed, sorry for not explaining it completely.
I think there used to be (or is) a property to the account of a folder
though. I might have removed this from the public interface API (not
sure).
The account, however, is not the same as the parent folder store.
A parent folder store would be a much better API (so what you propose
sounds like a better idea anyway). You can still get to the account
instance by recursively walking the parents upwards until the type isn't
a folder anymore. That last one should then be the account.
Note , though, that both queues and store accounts can contain folders
and that in future or at present non-account-store types can be a folder
store too (there's nothing in the API nor contract that requires the
root folder store to be a store account).
Only that it's a folder store, just like its children folders are. Which
is of course how the tree-idea is build.
> > I might agree with a patch that adds this API. Mind though that not
> > every folder strictly has to be inside another folder store.
> >
> > Currently will all folders exist within another folder store, but it's
> > not any current API contract whatsoever.
>
> Well the class diagram says that every folder has exactly one folder
> store IIRC.
That means that my class diagram is actually wrong. It should be zero or
one. Well, actually not even one but zero or more. As I don't see a
reason for a folder to be in exactly one folder store. A folder might
very well be in more than one folder store.
That would just add a reference to the folder ...
So I think the best relation here would be that a folder has zero or
more folder stores, and a folder store has zero or more folders.
It's just that this type of stuff hasn't really been tested a lot (for
example reference counting has to be correct in all situations).
> But anyway, just for knowing, which ones wouldn't have a
> folder store as parent?
Well at this moment there wouldn't be any. Nothing in the framework will
allow you to create one. But that is only because I made the constructor
of TnyCamelFolder a private one. By that I mean that it used to be
possible (but wrong, to use that constructor publicly, Which is why I
made it a private one).
However. The framework does allow for having your own implementation of
a TnyFolder. And for those instances, while it might be true that
they'll have a parent folder store, I also don't see a reason why it
(such a folder instance) *must* have a parent folder store.
> > So your API can return NULL (at least document it that way then).
> OK.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]