Skip to content

Instantly share code, notes, and snippets.

@igorw
Last active December 11, 2015 12:28
Show Gist options
  • Save igorw/4600419 to your computer and use it in GitHub Desktop.
Save igorw/4600419 to your computer and use it in GitHub Desktop.
Comments: Autoload path depth insanity

Comments: Autoload path depth insanity

Please leave your comments for the Autoload path depth insanity blog post on this gist.

Any type of feedback is welcome. Including alternate suggestions, corrections, insults, etc. Thanks!

P.S.: I apologize for the crappy format. I will try go get a better way to post comments soon, promise!

@Seldaek
Copy link

Seldaek commented Jan 29, 2013

FWIW, I agree. It would be a small improvement.

On the other hand, I think PSR-0 has bigger issues, namely I'd like to be able to separate classes on the file system for logical grouping while browsing, but still have them in the same namespace because they belong together and that would reduce use-hell.

For example, all the Exception subnamespaces make no sense IMO. Why should I use Vendor\MyLib\Exception\FooBarException; from Vendor\MyLib\Logic? Simply throwing FooBarException would be easier, but if I want to stow away my exception classes under a subdir to avoid cruft in the main one, I have to use a different namespace.

Obviously this would be a broader divergeance from PSR-0, and I am not sure if there is a way to define rules to allow this to work as I want without allowing a mess to emerge. Obviously I could already use classmap right now to do this, but as @igorw pointed out, that has drawbacks too. Anyway just throwing this out here, in case someone else has an idea.

@Crell
Copy link

Crell commented Feb 10, 2013

A number of people have raised a similar issue in Drupal as we've been pulling in more and more 3rd party libraries. I like this idea overall. Please do submit it to FIG for discussion. :-)

@AmyStephen
Copy link

I am so glad to see this raised @igorw Earlier today, I made a suggestion in the PSR forum regarding this issue.

My suggestion is simple. No programming changes. No standards changes. Just a change in the practice of how these package repositories are created.

If we use a folder structure for the packages (components), like this:

http://s7.postimage.org/7ar0rbvmz/Screen_shot_2013_02_10_at_9_04_50_AM.png

And, use class maps for unit testing, Composer and Packagist install the package neatly under the Vendor folder and there is only one occurrence (not two) of the Vendor/Package layer.

I posted my question https://groups.google.com/forum/#!topic/php-fig/-BPdegzme_Y - although I should have been more clear -- the discussion seems to be heading into areas other than this double layers of the Vendor/Package issue.

Would using the directory structure pictured above for packages be a reasonable solution?

@AmyStephen
Copy link

@Seldaek - the issues you are raising are important, in fact, it leads into best practices for overrides. As a separate discussion, It would be good to see your topic further discussed, as well.

@erikaheidi
Copy link

Well, I don't have much to add in this discussion, just would like to say that I honestly like the idea and Im sure this would have helped me when I first started to work with psr-0 autoload. I remember very well how I hated the folder verbosity when I realised that I NEEDED to use this crazy structure, even for something very simple. [+1]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment