[haiku-development] Re: Introducing a new namespace?
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 27 Jun 2009 19:36:05 +0200
-------- Original-Nachricht --------
> Datum: Sat, 27 Jun 2009 19:19:34 +0200
> Von: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> during discussions about the different classes and interfaces in the
> locale
> kit, Adrien and me had the idea of introducing a new namespace
> "BImplementor", that would be used to define interfaces that are not
> visible
> to the public, but are meant to be implemented in order to provide a
> certain
> functionality (maybe even by a third-party).
>
> The specific setup we're having is that there's a public class, BCatalog,
> which works as a proxy for concrete catalog type implementations.
> Currently, the base class for these implementations is name BCatalogAddOn,
> which is a complete misnomer, as it does not have much to do with add-ons,
> but defines the interface for each catalog usable by the locale kit.
>
> So BCatalog is the only class that shall be used by an app developer - it
> keeps a reference to the actual implementation and passes on all requests
> to
> that object.
> The BCatalogAddOn class should not really be visible to the app developer,
> however, it makes no sense to put it into BPrivate either, as it is not
> experimental or anything like that.
BPrivate isn't about being experimental. I'd even say experimental (i.e. in the
future possibly public) API should not live in BPrivate, but rather in the
namespace it would finally end up (i.e. none, respectively the B*
non-namespace, or something like BExperimental). If your class is private,
putting it into BPrivate is the thing to do IMO.
> So I had the idea of introducing the BImplementor namespace for that, such
> that BCatalogAddOn could be renamed to BImplementor::Catalog.
>
> Would that be acceptable or shall we stick to BPrivate as the only
> namespace
> for now?
I'm generally not opposed to introducing new namespaces, but don't really see a
reason for this one.
CU, Ingo
Other related posts: