You can clone with
HTTPS or Subversion.
PSR-0 is a standard which is almost 2 years old and requires that classes translate directly to paths: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md. Our module and plugin structure does not. This would mean altering the module structure removing the lib/modname part from the structure and moving everything into the module root (as was originally proposed).
We could then adopt Symfony2's bundle structure which places non-classes in a Resources folder. All of this could be achieved making it backwards compatible.
The next thing is we need to move away from PEAR naming, to namepsaces, so we can alter the loader to translate _ and \\ to be the same, this will allow easy refactoring and BC at the same time.
Lastly, in order to make the module structure entirely PSR-0 compliant, the modules/ folder would need an uppercase first letter, Modules\.
Lastly, there have been many complaints that the file naming makes it very difficult to know what file is which in IDE's like Eclipse and NetBeans. Adding the naming standards we apply to Exception classes and Abstracts/Interfaces would help, i.e. Controller\Admin.php would be Controller\AdminController.php
The module structure would look something like this
All this can be done with BC to the old structure.
@Guite, @jusuff, @planetenkiller, @tfotis, @hvorragend
Why is the development of the master branch is so active?
Shouldn't we care about the other problems first and fix the bugs in release 1.3 branch?
I think we are wasting too much time in the master branch now.
We should rather focus on module development, on the AppStore and on our website.
How does it help us if we have the best score, but no users and no modules?
+1000 to Carsten's OT comment.
I am sorry but this is necessary for conversion to namespacing. As for activity on the release-1.3, development is open, and people may actively submit pull request patches against it, nothing is stopping anyone.
The master branch moves us into a direction as we have always planned, getting us away from many self developed technologies and re-using libraries so we have less maintenance work. I'm not going to justify my work on the master branch - this is exactly what we planned.
Unless there is some constructive discussion on the issues in this ticket I will just proceed to make the changes, they are BC anyway requiring very small tweaks to our autoloaders.
IMHO the "lib/modname" structure under the module directory was a bad idea from the start and should have been avoided. Getting rid of this is a good thing as long as backward-compatability is provided.
BTW, I think things like "Foo\Controller\AdminController.php" is another example of overkill naming conventions ... if the file is in the Controller directory, why does it have to be called "Controller"? IMHO stuff like this doesn't serve a sane purpose other than overstating the obvious.
+1 for the change.
And +1 for Robert's note.
The simpler - the better.
@rgasch @jusuff I understand your point of view but the naming standard is actually very sensible when you look at the reasoning. Class names and file names follow a certain standard. If you have Foo\Api\Admin and Foo\Controller\Admin open at the same time you have no idea which class is which in an IDE. Secondly, class names are referenced in the shortcut because of the namespace and use declarations, so if you are using classes like this inside a class then you have no idea what they are since you have code that just says $foo = new Admin().
$foo = new Admin()
This is why you actually need to suffix the classes with what they are, This is not required in PEAR because you specify the full class name, but in namespaced classes it's pretty much required.
Sure about the meaning of your arguments.
And the more issues will come the more all participants will be overworked.
In this case I think it's more important when someone introduce the one or another issue.
I wish that we don't forget to work first for a Version 1.3.2 that works. There is enough to do.
Over 70 issues for the core.
The IDE issue is a poor argument for such change IMO.
I use NetBeans and the tooltip of the current document tab has the full path.
Aptana in the other hand, makes the context pretty clear. This needs another good reason.
I like the current classes structure pretty much,
and I would like to see a clear example of Namespaces issues,
maybe I will face it soon, but ModUtil initially handles the API <-> Controller layers.
This change is now supported in 1.3.6