Re: Why does this not exist?

[Philip Van Hoof <spam pvanhoof be>]

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.