Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having some trouble working this one out, probably more than I should. This is a pretty large project, with a very clearly defined structure, with no obvious problems, but I can't seem to figure out the optimal solution for this case, even after reading several convention documents and such.

For example, given the following namespace:


Obviously it refers to a "view" namespace...which technically also has a 'view' class in it:


This is clearly not ideal, but I can't come up with a better way to name these. Take for example the cache namespace:


Same deal, the cache class becomes confusing when inside this namespace:


Should I just move these 'core' classes from their namespaces, and put them in the parent namespace?

\vendor\core\lib\cache (class)
\vendor\core\lib\cache\adapter\redis (class)

Or is there a better term to refer to these types of classes?

Pardon my circularity, it's a bit late and my head's not quite working in optimal condition.

share|improve this question

migrated from Sep 14 '11 at 10:20

This question came from our site for professional and enthusiast programmers.

It's difficult to decipher what you're asking. – Herbert Sep 14 '11 at 2:33
up vote 2 down vote accepted

By convention, class names should be uppercase and namespaces lowercase, so it's not "confusing" to do what you're doing:

use \vendor\core\lib\cache\Cache;
share|improve this answer
It may not be confusing, but it is a little untidy. If Cache is the only class in the cache namespace, then does it really need it's own namespace? \vendor\core\lib\Cache would be more appropriate. Alternatively, if there are more than one class in cache namespace, is the name cache really appropriate? – Gavin Coates Sep 14 '11 at 10:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.