Top level <NamespaceName> confusion in PSR-4

[Sergey Lukin]

Hi,

I find this statement from PSR-4 confusing:

The fully qualified class name MUST have a top-level namespace name, also known as a "vendor namespace".

I don't understand how "also known as" should be interpreted here? It's not a "MUST" nor is it a "MAY"...

For practical example, my app (not a package) consists of classes with following fully qualified names: \Controllers\AboutUs, \Models\User, etc.

I'm using Composer's PSR-4 autoloader to load them. If I'd have a class I'd prefer to share/use externally, I'd wrap it in a package with following fully qualified name: \<NameOfOrganization>(\<ProjectName>)?(\<SubNamespaceNames>)*\<ClassName> and update all references accordignly.

Is there anything from what I described that is not valid according to PSR-4? If there is, could you please help me understand why and how it may be bad for my app?

Thank you! :)

[Moshe Brevda]

NameOfOrganization would be your "vendor namespace", which you're currently missing. 

It may not be bad for your app per se, but imagine if your organization were to have two apps, that both had controllers. How would the autoloader know to differentiate between app1\Controllers and app2\Controllers? (same if part of your controllers were to be moved to their own library.)

Think of it as being your domain name with ".com" without providing a unique name before that!

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/57bdadd6-0e96-451e-b56c-4cf1d47f0319%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alessandro Pellizzari]

On Sat, 4 Jul 2015 23:51:55 -0700 (PDT)
Sergey Lukin <con...@sergeylukin.com> wrote:

> Hi,
>

> I find this statement from *PSR-4* confusing:

>
> The fully qualified class name MUST have a top-level namespace name,
> also
> > known as a "vendor namespace".

I think that refers to framework and components developers.

> For practical example, my app (not a package) consists of classes

> with following fully qualified names: *\Controllers\AboutUs*,
> *\Models\User*, etc.
> I'm using Composer's *PSR-4* autoloader to load them. If I'd have a

> class I'd prefer to share/use externally, I'd wrap it in a package
> with following fully qualified name:

> *\<NameOfOrganization>(\<ProjectName>)?(\<SubNamespaceNames>)*\<ClassName>*

> and update all references accordignly.
>
> Is there anything from what I described that is not valid according

> to *PSR-4*? If there is, could you please help me understand why and

> how it may be bad for my app?

I do about the same. But I use App as top-level namespace for my
application, and use modules inside it, so I have
App\StockManagement\Controller\MainController and so on.

This way I have a single "entry-point" for the autoloader.

As a follow-up to Moshe, in my organization, if we have 2 apps, they
are in 2 different repos. We don't autoload parts of an app from
another. If there are common components, we tranform them in components
and they end up in vendor/ under the company's namespace, as any other
component.

Bye.

[Jason Judge]

On Sunday, 5 July 2015 14:33:35 UTC+1, Moshe Brevda wrote:

NameOfOrganization would be your "vendor namespace", which you're currently missing. 

It may not be bad for your app per se, but imagine if your organization were to have two apps, that both had controllers. How would the autoloader know to differentiate between app1\Controllers and app2\Controllers? (same if part of your controllers were to be moved to their own library.)

Think of it as being your domain name with ".com" without providing a unique name before that!

It is also true that composer will be happy to load a "psr-0" or "psr-4" package without it having a vendor part to the namespace. Does that mean some application code loaded using a PSR-4 autoloader is not fully compliant with PSR-4? Yes, I guess it does, and that will reduce its interoperability if you want to use it in another application. That code would never be published as a "PSR-4 compliant package". But feel free to use the PSR-4 autoloader within your application - you aren't breaking any laws :-)

-- Jason

[Larry Garfield]

On 7/6/15 3:52 AM, Jason Judge wrote:
> On Sunday, 5 July 2015 14:33:35 UTC+1, Moshe Brevda wrote:
>

> *NameOfOrganization*would be your**"vendor namespace",

Correct. Most PSR-4 compatible autoloaders don't enforce global
uniqueness or that the top level namespace is in some magic "vendor"
list. They just work by string mangling and you're fine.

The purpose of the vendor level is to encourage interoperability by,
effectively, making all classes in the PHP world have a GUID class
name. That makes "this class is already loaded, what are you trying to
do?" problems go away almost entirely (unless you're doing some specific
hacking of autoload ordering, in which case you're on your own).

The top level namespace could be a company name, project name, or the
developer's name/handle. The point is to NOT assume that your project
is the entire universe, even if it is app-specific code. Thus,
\Controller, \Form, \User, etc. as in effect your app trying to lay
claim to the entire universe of Controllers, Forms, and Users. You
likely don't mean that. :-)

One of the advantages of PSR-4 over PSR-0 is that you can have that
extra namespace layer for your application without needing to have an
otherwise-useless directory on disk to click through every time you want
to get to your code. That's the point. :-) You can have your vendor and
not-navigate it too.

--
--Larry Garfield