Are studly caps for namespaces the standard?

[Beau Simensen]

Do any projects use lowercase or camel case names for namespaces? As far as I can tell it is allowed by PSR-0 and it doesn't look like PSR-1 makes any recommendation on the issue — as far as I can tell it only addresses the class name (studly caps).

I ask because I don't think I've run into any code (other than my own) that uses anything other than studly caps for namespaces. I'm wondering if this is a universal thing (and should work on adjusting any new code to follow this unstated agreed upon standard) or if it isn't the only way people do it (and I haven't looked hard enough and that I should feel OK continuing to do namespaces however I like as long as they follow PSR-0).

I ask also because it is possible I missed something big in PSR-0 or PSR-1 and it does actually address this. If so, please help me see where it is as I've looked a few times and it has never popped out at me. :)

[Beau Simensen]

Actually, it also possible I don't know exactly what camelCase and StudlyCaps mean RE: the PSR's. In my mind camelCase always has first letter lowercase, and I assumed StudlyCaps was the same except first letter was uppercase. :)

[William Durand]

Heya,

The testing framework Atoum (https://github.com/mageekguy/atoum) uses lowercase names for namespaces.

--

William Durand | http://www.williamdurand.fr

2012/4/13 Beau Simensen <sime...@gmail.com>

Do any projects use lowercase or camel case names for namespaces? As far as I can tell it is allowed by PSR-0 and it doesn't look like PSR-1 makes any recommendation on the issue — as far as I can tell it only addresses the class name (studly caps).

I ask because I don't think I've run into any code (other than my own) that uses anything other than studly caps for namespaces. I'm wondering if this is a universal thing (and should work on adjusting any new code to follow this unstated agreed upon standard) or if it isn't the only way people do it (and I haven't looked hard enough and that I should feel OK continuing to do namespaces however I like as long as they follow PSR-0).

I ask also because it is possible I missed something big in PSR-0 or PSR-1 and it does actually address this. If so, please help me see where it is as I've looked a few times and it has never popped out at me. :)

--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/php-standards/-/snhzGk4Q0SAJ.
To post to this group, send email to php-st...@googlegroups.com.
To unsubscribe from this group, send email to php-standard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/php-standards?hl=en.

[Paul M. Jones]

On Apr 12, 2012, at 3:11 PM, Beau Simensen wrote:

> Do any projects use lowercase or camel case names for namespaces?

The Lithium guys use lowercase; Aura used to, but switched to StudlyCaps. There may be others.

> As far as I can tell it is allowed by PSR-0 and it doesn't look like PSR-1 makes any recommendation on the issue — as far as I can tell it only addresses the class name (studly caps).

This is correct. PSR-0 uses both lowercase and StudlyCaps examples, and makes no recommendation either way. PSR-1 defers to PSR-0 on namespaces, but does formalize the class naming conventions. Class names in all the ancestor standards (notably PEAR) were all StudlyCaps, and as such seems to be the supermajority practice.

> I ask because I don't think I've run into any code (other than my own) that uses anything other than studly caps for namespaces. I'm wondering if this is a universal thing (and should work on adjusting any new code to follow this unstated agreed upon standard) or if it isn't the only way people do it (and I haven't looked hard enough and that I should feel OK continuing to do namespaces however I like as long as they follow PSR-0).

StudlyCaps isn't the *only* way people do it, but it does seem to be the way the vast majority are doing it. I used to use lowercase for namespaces, but after seeing that practically the rest of the world was using StudlyCaps, the decision to switch was easy. In a lot of ways, StudlyCaps is an easier transition when moving away from PEAR_Style_ClassNames to Name\Space\ClassNames: replace the _ with \ and you're done.

> I ask also because it is possible I missed something big in PSR-0 or PSR-1 and it does actually address this. If so, please help me see where it is as I've looked a few times and it has never popped out at me. :)

As far as I can tell, you have missed nothing. :)

-- pmj

[Kinn Julião]

Enhance-php(www.enhance-php.com) uses StudlyCaps. I think this question is more usual than standard.

2012/4/12 William Durand <william...@gmail.com>

--

------------------------------------------------------

OpenSource evangelist

 www.kinncj.com.br

 www.phpformeego.org 

 www.phpforandroid.net
 www.phpedia.org
developer.appcelerator.com

------------------------------------------------------

[Paul Scott]

On 13/04/2012 00:11, Beau Simensen wrote:
> Do any projects use lowercase or camel case names for namespaces? As
> far as I can tell it is allowed by PSR-0 and it doesn't look like

> PSR-1 makes any recommendation on the issue � as far as I can tell it

> only addresses the class name (studly caps).

Chisimba pre v4 used to use lower case, but has since changed. IMO there
is no real big deal, but studly does actually read a little better now
that I am using it across the board.

-- Paul

[Miles J]

I use lowercase in all my projects.

To me, classes are first-class files on the filesystem, and as such should be capitalized (and even more so to match the actual class name). Folders are just second-class containers and as such shouldn't be capitalized. I also follow Java's packaging conventions for the most part, where everything is lowercased.

[Larry Garfield]

Drupal is using UpperCaps, with a few exceptions for module names (which
are lower-case for historical reasons) where it's just easier to have
them match. So we're using a little of each for technical reasons. :-)

--Larry Garfield

On 04/12/2012 05:11 PM, Beau Simensen wrote:
> Do any projects use lowercase or camel case names for namespaces? As
> far as I can tell it is allowed by PSR-0 and it doesn't look like

> PSR-1 makes any recommendation on the issue � as far as I can tell it

> only addresses the class name (studly caps).
>
> I ask because I don't think I've run into any code (other than my own)
> that uses anything other than studly caps for namespaces. I'm
> wondering if this is a universal thing (and should work on adjusting
> any new code to follow this unstated agreed upon standard) or if it
> isn't the only way people do it (and I haven't looked hard enough and
> that I should feel OK continuing to do namespaces however I like as
> long as they follow PSR-0).
>
> I ask also because it is possible I missed something big in PSR-0 or
> PSR-1 and it does actually address this. If so, please help me see
> where it is as I've looked a few times and it has never popped out at
> me. :)

[Marc Ermshaus]

(Apologies if this has been discussed before. I did read most but not all of the PSR-1 discussion.)

Lower-case namespaces are a way to differentiate between namespaces and classes.

    use Assetic\Util\Process;
    use Assetic\Filter\GoogleClosure;

In this example, Process is a class, GoogleClosure is a namespace. Without prior knowledge, there is no way of knowing.

If the code is written like this…

    use assetic\util\Process;
    use assetic\filter\googleclosure;

…the distinction becomes obvious.

This might be considered an advantage of lower-case namespaces.

As others pointed out, the usage of namespaces in upper camel case format (Assetic\Util) might originate from nothing but an inconsiderate conversion of PEAR-style class names (Assetic_Util_Process) in which the (solely semantic) namespace was an integral part of the class name and class names had to be written in upper camel case for stylistic reasons (that corresponds to PSR-1). With the introduction of syntactical namespaces, there is now a clear distinction between the non-qualified class name (Process) and the fully qualified class name (abbr. FQCN) with the latter containing the namespace (Assetic\Util\Process).

Is there a good reason for namespaces to inherit the stylistic requirement of upper camel case for class names?

Personally, I can understand why class names like assetic_util_Process were frowned upon. This scheme would be a violation of most PHP style guides I have ever read: “A class name has to start with a capital letter.”

But I don’t feel the same about FQCNs. assetic\util\Process is perfectly fine with me. $process = new \assetic\util\Process(); No problem. Doesn’t make me cringe. I’m pretty sure that has to do with influences from other languages such as Java: “Package names should be lower-case.”

[Andreas Möller]

-1

--

You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/php-standards/-/cODWxVZNU6kJ.

[Andreas Möller]

> Lower-case namespaces are a way to differentiate between namespaces and classes.
>
> use Assetic\Util\Process;
> use Assetic\Filter\GoogleClosure;
>
> In this example, Process is a class, GoogleClosure is a namespace. Without prior knowledge, there is no way of knowing.

But, do you need to know?

How do you solve the problem that occurs when Assetic\Util\Process
becomes a namespace, i.e., when classes are added, e.g. a different
implementation is created, commonalities are abstracted, etc.?


Best regards,

Andreas

[Sebastian Krebs]

Hi,

2012/6/13 Andreas Möller <a...@softe.is>

> Lower-case namespaces are a way to differentiate between namespaces and classes.
>
>     use Assetic\Util\Process;
>     use Assetic\Filter\GoogleClosure;
>
> In this example, Process is a class, GoogleClosure is a namespace. Without prior knowledge, there is no way of knowing.

But, do you need to know?

But is there a reason, why one should _not_ know? I can't find a valid reason, why there is no distinction between classes and namespaces and this distincintion would make the difference obvious at all. At least: Why should FIG _prohibit_ anyone from taking the opportunity to _make_ a distinction? In my oppinion it should encourage to take this opportunity (not "enforce", because looking at all the existing frameworks/libraries this would be a really ugly mess :D)

 

How do you solve the problem that occurs when Assetic\Util\Process
becomes a namespace, i.e., when classes are added, e.g. a different
implementation is created, commonalities are abstracted, etc.?

What problem? 'Assetic\Util\Process' (lets name it 'assetic\util\Process' for this short paragraph) itself couldn't become a namespace, because the correspondin namespace would be 'access\util\process'. Because this namspace didn't exists before it cannot collide with existing code. The class 'assetic\util\Process' remains as it is, so it doesn't break anything too. Everything works fine, so where is a problem?

 

Best regards,

Andreas

Regards,

Sebastian

 

--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.

[Matthew Lanigan]

On Wed, Jun 13, 2012 at 7:53 AM, Sebastian Krebs <kreb...@googlemail.com> wrote:

Hi,

2012/6/13 Andreas Möller <a...@softe.is>

> Lower-case namespaces are a way to differentiate between namespaces and classes.
>
>     use Assetic\Util\Process;
>     use Assetic\Filter\GoogleClosure;
>
> In this example, Process is a class, GoogleClosure is a namespace. Without prior knowledge, there is no way of knowing.

But, do you need to know?

But is there a reason, why one should _not_ know? I can't find a valid reason, why there is no distinction between classes and namespaces and this distincintion would make the difference obvious at all. At least: Why should FIG _prohibit_ anyone from taking the opportunity to _make_ a distinction? In my oppinion it should encourage to take this opportunity (not "enforce", because looking at all the existing frameworks/libraries this would be a really ugly mess :D)

 

It is not true that you don't know. You can still determine just as easily programmatically if the class exists, and you should know whether it exists when you are using it in the first place. The distinction in capitalization does nothing in this regard.

 

How do you solve the problem that occurs when Assetic\Util\Process
becomes a namespace, i.e., when classes are added, e.g. a different
implementation is created, commonalities are abstracted, etc.?

What problem? 'Assetic\Util\Process' (lets name it 'assetic\util\Process' for this short paragraph) itself couldn't become a namespace, because the correspondin namespace would be 'access\util\process'. Because this namspace didn't exists before it cannot collide with existing code. The class 'assetic\util\Process' remains as it is, so it doesn't break anything too. Everything works fine, so where is a problem?

In this case you are required to execute two use statements, e.g.

use assetic\util\Process;

use assetic\util\process;

$some_var = process\some_func(new Process());

 

As namespace names and class names don't occupy the same... namespace, they can overlap without any problem and so I can't see the meaning behind making the distinction between namespaces and classes.

Matthew Lanigan

[Sebastian Krebs]

2012/6/13 Matthew Lanigan <rin...@gmail.com>

On Wed, Jun 13, 2012 at 7:53 AM, Sebastian Krebs <kreb...@googlemail.com> wrote:

Hi,

2012/6/13 Andreas Möller <a...@softe.is>

> Lower-case namespaces are a way to differentiate between namespaces and classes.
>
>     use Assetic\Util\Process;
>     use Assetic\Filter\GoogleClosure;
>
> In this example, Process is a class, GoogleClosure is a namespace. Without prior knowledge, there is no way of knowing.

But, do you need to know?

But is there a reason, why one should _not_ know? I can't find a valid reason, why there is no distinction between classes and namespaces and this distincintion would make the difference obvious at all. At least: Why should FIG _prohibit_ anyone from taking the opportunity to _make_ a distinction? In my oppinion it should encourage to take this opportunity (not "enforce", because looking at all the existing frameworks/libraries this would be a really ugly mess :D)

 

It is not true that you don't know. You can still determine just as easily programmatically if the class exists, and you should know whether it exists when you are using it in the first place. The distinction in capitalization does nothing in this regard.

Nobody said something about what the application sees, but what the developer sees, when he looks at the 'use'-statements the first time. Does it refer to a class, a namespace, or even both?

 

 

How do you solve the problem that occurs when Assetic\Util\Process
becomes a namespace, i.e., when classes are added, e.g. a different
implementation is created, commonalities are abstracted, etc.?

What problem? 'Assetic\Util\Process' (lets name it 'assetic\util\Process' for this short paragraph) itself couldn't become a namespace, because the correspondin namespace would be 'access\util\process'. Because this namspace didn't exists before it cannot collide with existing code. The class 'assetic\util\Process' remains as it is, so it doesn't break anything too. Everything works fine, so where is a problem?

In this case you are required to execute two use statements, e.g.

use assetic\util\Process;

use assetic\util\process;

$some_var = process\some_func(new Process());

Don't know exactly, but wasn't it discouraged to refer to namespaces in 'use'-statements anyway? In this case the lowercase-notation is even better, because you see, that your statement is right, or wrong and you cannot accidentally treat a class refered by the 'use'-statement as namespace like 'new Process; new Process\SpecialOne;'

(As a sidenote: I would call it 'assetic\util\processes' (or something like that) anyway, because its a "space" and not a single entity)

 

 

As namespace names and class names don't occupy the same... namespace, they can overlap without any problem and so I can't see the meaning behind making the distinction between namespaces and classes.

Yeah, I know, but is the argument, that they _can_ a reason, that they _should_? On the other hand the reason, why it feels useful to me to distinguish between classes and namespaces, is, that they are no the same. So ... just "why"?

It seems like you are focusing on the technical aspects and of course the interpreter doesn't care, but that wasn't the point. Most aspects of style guides have no deeper technical meaning.

I must say, that I don't ^really^ care, because I lived with this notation for a while now, even if it is only the second best solution imo. However, now I'm really curious, why nobody can give an argumentat for it, that goes beyond "Why not?" Maybe I missed something (because I don't read every mail).

Regards,

Sebastian

[Anthony Ferrara]

Sebastian,

One point that I think is worth considering is that to the runtime,
there is no such thing as a namespace. It's a compiler aided string
replace. That's it. There's no namespace construct in the code.
There's no logic based on namespace name at runtime. The classes name
literally becomes "\Foo\Bar\ClassName".

Based on that, shouldn't it follow the same rules for class names,
seeing as that's how it's going to resolve anyway?

And who cares if there is a collision between a class name and a
namespace? It would allow me to do:

\Foo\Bar\Cache - The interface to resolve
\Foo\Bar\Cache\Apc - A class implementing the interface

My $0.02

Anthony

On Wed, Jun 13, 2012 at 8:49 AM, Sebastian Krebs

[Sebastian Krebs]

2012/6/13 Anthony Ferrara <ircm...@gmail.com>

Sebastian,

One point that I think is worth considering is that to the runtime,
there is no such thing as a namespace. It's a compiler aided string
replace. That's it. There's no namespace construct in the code.
There's no logic based on namespace name at runtime. The classes name
literally becomes "\Foo\Bar\ClassName".

As mentioned I know the technical aspects and I know, that the interpreter makes no difference. But you can name your variables "$jkdasdsja" and you don't do it ;). That it works, doesn't mean, that it must get used, or that leads to better code, or whatever.

 

Based on that, shouldn't it follow the same rules for class names,
seeing as that's how it's going to resolve anyway?

The question remains: _Why_ should it? What do I gain, when naming both the same?

Maybe its important to mention, that even PSR-0 doesn't make any assumption of the case.

 

And who cares if there is a collision between a class name and a
namespace?

The new employee, who must find out, which of the 'use'-statements refer classes and which namespaces ;) Feels like I always write the same things within all 3 mails so far, but my point remains, that separating both means, that both are distinguishable on the very first look, whereas the current state ist ambiguous. Not for the interpreter, probably not for the one, who wrote the code, but for others.

 

It would allow me to do:

\Foo\Bar\Cache - The interface to resolve
\Foo\Bar\Cache\Apc - A class implementing the interface

OK, thats a least comprehensible argument, even if I don't the a benefit here. Why is it "good", that you can do this? Or why is it better, than

\foo\bar\Cache;

\foo\bar\caches\APC;

Within the code itself in both cases only "new Cache;" and "new APC" remains, so no difference there.

It even allows such (in my eyes) ugly things like "new APC; new Cache\APC;" within the same file. (Thats not a real argument, just a comment)

Additional it seems cleaner, if the interface resides in the same namspace as it's (default-)implementations, but thats another story ;)

[Anthony Ferrara]

Sebastian,

> As mentioned I know the technical aspects and I know, that the interpreter
> makes no difference. But you can name your variables "$jkdasdsja" and you
> don't do it ;). That it works, doesn't mean, that it must get used, or that
> leads to better code, or whatever.

Well, the technical concerns do matter. Because to me, if it isn't a
first-class citizen, it doesn't deserve its own naming conventions.
Namespaces are not first-class, therefore they don't deserve their own
convention. IMHO...

> The question remains: _Why_ should it? What do I gain, when naming both the
> same?

Consistency. Do we have naming conventions for exception messages,
which are also not first-class? Where is the line drawn?

> Maybe its important to mention, that even PSR-0 doesn't make any assumption
> of the case.

Actually, it does. It makes the assumption that the symbol case
matches the filesystem case...

> The new employee, who must find out, which of the 'use'-statements refer
> classes and which namespaces ;)

No, you don't. You need to look at the namespaces, and remember that
"use Foo\Bar\Baz as Biz" means "Any time I see Biz, remember that it
means Foo\Bar\Baz"...

For example:

use Foo\Bar\Baz;

$foo = new Baz;

vs

$foo = new Baz\Biz;

vs

$foo = new \Foo\Barb;

The point is that, since it's automated string replace, `use` and `use
as` are really just sugar.

In fact, I don't think it's worth while distinguising classes from
namespaces, because your workflow is the same.

$foo = new bar\Baz;

To figure out where the class is defined, you still need to resolve
the "bar" from the use statement. Which means I still need to go to
the top of the file to figure out what to replace it with (to
determine the FQCN). The same goes for new Baz. Unless it's prefixed
by a \, you need to "resolve" the class name anyway. So what do you
save by naming the namespace differently? You still need to resolve it
yourself...

> OK, thats a least comprehensible argument, even if I don't the a benefit
> here. Why is it "good", that you can do this? Or why is it better, than
>
> \foo\bar\Cache;
> \foo\bar\caches\APC;
>
> Within the code itself in both cases only "new Cache;" and "new APC"
> remains, so no difference there.

Because it implies relation. This way, there's no relation implied
until you comprehend that "caches" is plural of "Cache". Which can be
difficult to do automatically, and at first glance may seem odd...

> It even allows such (in my eyes) ugly things like "new APC; new Cache\APC;"
> within the same file. (Thats not a real argument, just a comment)

It allows, but that doesn't mean that you should do it...

> Additional it seems cleaner, if the interface resides in the same namspace
> as it's (default-)implementations, but thats another story ;)

Sometimes I would agree with you. Sometimes not. I think it comes down
to the problem at hand...

Anthony

[Drak]

On 13 June 2012 19:38, Anthony Ferrara <ircm...@gmail.com> wrote:

And who cares if there is a collision between a class name and a
namespace?  It would allow me to do:

\Foo\Bar\Cache - The interface to resolve
\Foo\Bar\Cache\Apc - A class implementing the interface

Actually the better way is this

 

\Foo\Bar\Cache\CacheInterface - The interface to resolve

\Foo\Bar\Cache\Apc - A class implementing the interface

Or even better:

\Foo\Bar\Cache\ApcCache - A class implementing the interface

Good examples are with controllers.

Basically the idea is to prefix the class name with Abstract if it's abstract, and suffix with Interface if a interface and in other circumstances where there may be lots of common class names, to write what it is since in the code with namespaces, we are only using the class name. It's much more readable to have $controller = new AdminController() than $controller = new Admin(). Generally, suffixing classes with what they are helps a lot with readability.

Drak

[Andreas Möller]

And who cares if there is a collision between a class name and a
namespace?  It would allow me to do:

\Foo\Bar\Cache - The interface to resolve
\Foo\Bar\Cache\Apc - A class implementing the interface

Actually the better way is this

 

\Foo\Bar\Cache\CacheInterface - The interface to resolve

\Foo\Bar\Cache\Apc - A class implementing the interface

Or even better:

\Foo\Bar\Cache\ApcCache - A class implementing the interface

This may not always be possible due to backward compatibility reasons. 

Good examples are with controllers.

Basically the idea is to prefix the class name with Abstract if it's abstract, and suffix with Interface if a interface and in other circumstances where there may be lots of common class names, to write what it is since in the code with namespaces, we are only using the class name. It's much more readable to have $controller = new AdminController() than $controller = new Admin(). Generally, suffixing classes with what they are helps a lot with readability.

For ZF2, as far as I recall it, exactly this scheme has been voted for (including traits). Unfortunately, it hasn't been voted for consistency ("always suffix") which I would have found a lot better, especially since you'd find all the classes by each other and also because of auto-completion in IDEs that support it. 

Best regards,

Andreas

[mindplay.dk]

I recently posted this issue on Github:

https://github.com/php-fig/fig-standards/issues/36#issuecomment-6378436 

One consideration that didn't seem to come up in your discussion here, is the fact that classes, interfaces and traits have something in common: they're all types. As one of you pointed out, namespaces are just names, that happen to map to folders - they're not types. As such, it's rather misleading to capitalize them as if they were types - it would make no more sense than capitalizing local variable-names; they're just names.

Also consider the "vendor/package" naming-convention in all-lowercase for (e.g. Composer) packages. Since the PSR recommendation is "vendor\package" for namespaces, using consistent conventions for these names is preferable to me.

Unfortunately, some of the earliest mainstream packages to use namespaces set forth a widely accepted convention of capitalizing namespaces, so it may be too late to convince the community to change.

I personally changed my mind, and will be using lowercase for namespaces, but I don't think PSR should enforce (or even recommend) anything one way or the other. I haven't heard a rational argument for capitalizing namespaces, and the above arguments are rational to me, but I don't want to cause trouble for large, established project maintainers, and their followers, who have already settled on capitalized namespaces.

There is something to be said for consistency, but I think it's too late to "legislate" on this one.

The PSR should be updated to clarify the fact that either capitalized or lowercase are both fine though.