On Fri, Mar 20, 2015 at 12:51 PM, Bryan Davis <bd808(a)wikimedia.org> wrote:
The color I have picked for this namespace bikeshed
That means you need to map MediaWiki\Core to includes or includes/Core.
Given that we have a mediawiki/core repo containing a bunch of classes
which are not going to be in that directory (maintenance scripts, i18n),
that's a bit confusing. Also, what non-core subnamespaces do you expect? I
imagine all extensions would go under MediaWiki\Extension, which would make
the top-level namespace a bit underused.
The MediaWiki root namespace is a pretty obvious choice.
Just to play devil's advocate, we could also use a vendor schema
(Wikimedia\MediaWiki\...). That looks uglier but is better at preventing
conflicts as each vendor has its own subspace. PSR-0 actually required
this, but PSR-3 backed out of it.
I'd be fine with throwing Debug in between Core and Logger too
if consensus found for that instead.
Logger is fine IMO, it's the other log class that should eventually get a
more descriptive name.
I was thinking an includes/Core/ directory could be
used as the common
base for these and future namespaced classes in MediaWiki core.
If we intend to put all MediaWiki core classes under the Core namespace,
then the two-level directory structure seems a bit silly; MediaWiki\Core
should just map to a top-level directory. That can't be includes, because
not all OS-es have case-sensitive directory names and we don't want to
tiptoe around old directory names when choosing namespaces. Also we
probably want to enforce stronger code conventions for the new classes
(such as PSR-3 conformance) and automating that is easier when everything
in the same directory needs the same rules. So how about /src/Logger?
That's a fairly standard structure while "includes" has that nineties
flavor where you had your controllers in the apache docroot and the rest of
your classes were manually included from somewhere else...