DDC-400: Partial Namespace ClassLoader support #494

New Issue

admin · 2026-01-22T12:40:24+01:00

admin commented

2026-01-22 12:40:24 +01:00

Originally created by @doctrinebot on GitHub (Mar 10, 2010).

Jira issue originally created by user josiah:

A due to the way that the class loader is structured, it is not possible to have a sub-namespace pointing to a separate directory from the parent namespace.

When using Doctrine within the Zend Framework, this makes it impossible to have disparate folders containing different parts of code. Specifically, models are stored within the application/models directory, and the namespace for all classes within this directory is 'MyProject/Models'. So the 'Widget' model would reference the class 'MyProject\Models\Widget' within the file 'application/models/Widget.php'. In order to alleviate this issue, I have extended the ClassLoader to create a PartialNamespaceLoader that performs this functionality.

I would like to submit the attached patch for potential inclusion within Doctrine.

The patch contains Unit Tests, and the actual class, If any further changes, or additional work to the patch is required, I am willing to amend the patch or update it.

Originally created by @doctrinebot on GitHub (Mar 10, 2010). Jira issue originally created by user josiah: A due to the way that the class loader is structured, it is not possible to have a sub-namespace pointing to a separate directory from the parent namespace. When using Doctrine within the Zend Framework, this makes it impossible to have disparate folders containing different parts of code. Specifically, models are stored within the application/models directory, and the namespace for all classes within this directory is 'MyProject/Models'. So the 'Widget' model would reference the class 'MyProject\Models\Widget' within the file 'application/models/Widget.php'. In order to alleviate this issue, I have extended the ClassLoader to create a PartialNamespaceLoader that performs this functionality. I would like to submit the attached patch for potential inclusion within Doctrine. The patch contains Unit Tests, and the actual class, If any further changes, or additional work to the patch is required, I am willing to amend the patch or update it.

admin added the New Feature label 2026-01-22 12:40:24 +01:00

admin closed this issue

2026-01-22 12:40:25 +01:00

admin commented

2026-01-22 12:40:26 +01:00

@doctrinebot commented on GitHub (Mar 10, 2010):

Comment created by romanb:

The Doctrine ClassLoader follows a common convention and class organization that was agreed upon by many open source projects (http://groups.google.com/group/php-standards/web/psr-0-final-proposal). We want to encourage this style, because it makes everyone's lifes a bit easier. Therefore I see no chance of getting such a special class loader into Doctrine itself. If you still want to use it and share with others you can possibly do that as a Doctrine extension or simply on github/googlecode/etc.

The standard explained in short: All classes of a project or module are organized under a common root directory (i.e. "src" or "lib") and the directory structure from there on reflects the namespace and class name of the class. Thats all. Of course an application can have many subprojects / modules, in such a case each subproject/module simply has its own "src" folder and you configure multiple class loaders, one for each module/subproject. For example:

app/
   /module1
       /src
          /MyApp 
              /Module1
                 /Model
                    User.php // namespace MyApp\Module1\Model

   /module2
       /src
          /MyApp 
              /Module2
                 /Model
                    Role.php // namespace MyApp\Module2\Model

...

I dont know why the ZF imposes a class structuring on user's classes that is different from their own class organization. IMHO frameworks should promote the practices they use themselves.

The standard makes for very easy and streamlined class loading and you no longer need to use different class loaders from different libraries. One implementation to rule them all and class loading always works the same. This results in much less WTF caused by each library having its own special class loader that works differently.

p.s. If you can, try out the SplClassLoader PECL extension (http://github.com/metagoto/splclassloader) which implements the abovementioned standard and will eventually be included in future PHP releases.

@doctrinebot commented on GitHub (Mar 10, 2010): Comment created by romanb: The Doctrine ClassLoader follows a common convention and class organization that was agreed upon by many open source projects (http://groups.google.com/group/php-standards/web/psr-0-final-proposal). We want to encourage this style, because it makes everyone's lifes a bit easier. Therefore I see no chance of getting such a special class loader into Doctrine itself. If you still want to use it and share with others you can possibly do that as a Doctrine extension or simply on github/googlecode/etc. The standard explained in short: All classes of a project or module are organized under a common root directory (i.e. "src" or "lib") and the directory structure from there on reflects the namespace and class name of the class. Thats all. Of course an application can have many subprojects / modules, in such a case each subproject/module simply has its own "src" folder and you configure multiple class loaders, one for each module/subproject. For example: ``` app/ /module1 /src /MyApp /Module1 /Model User.php // namespace MyApp\Module1\Model /module2 /src /MyApp /Module2 /Model Role.php // namespace MyApp\Module2\Model ... ``` I dont know why the ZF imposes a class structuring on user's classes that is different from their own class organization. IMHO frameworks should promote the practices they use themselves. The standard makes for very easy and streamlined class loading and you no longer need to use different class loaders from different libraries. One implementation to rule them all and class loading always works the same. This results in much less WTF caused by each library having its own special class loader that works differently. p.s. If you can, try out the SplClassLoader PECL extension (http://github.com/metagoto/splclassloader) which implements the abovementioned standard and will eventually be included in future PHP releases.

admin commented

2026-01-22 12:40:26 +01:00

@doctrinebot commented on GitHub (Mar 10, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Mar 10, 2010): Issue was closed with resolution "Won't Fix"

admin commented

2026-01-22 12:40:28 +01:00

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 1 attachments from Jira into https://gist.github.com/41c83300a013bf8b4179

10441_partial-namespace-loader.patch

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 1 attachments from Jira into https://gist.github.com/41c83300a013bf8b4179 - [10441_partial-namespace-loader.patch](https://gist.github.com/41c83300a013bf8b4179#file-10441_partial-namespace-loader-patch)

admin referenced this issue

2026-01-22 15:59:12 +01:00

[PR #494] [CLOSED] Update lib/Doctrine/ORM/Persisters/BasicEntityPersister.php #8283

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#494