[wp-meta] [Making WordPress.org] #3692: Add CamelCase support from plugin names as per PSR-4 Autoloaders standard

[Making WordPress.org]

#3692: Add CamelCase support from plugin names as per PSR-4 Autoloaders standard
------------------------------+------------------------------------
 Reporter:  KestutisIT        |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Plugin Directory v3.0
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+------------------------------------

Comment (by KestutisIT):

 Replying to [comment:4 swissspidy]:
 > > Because autoloaders and namespaces will then won't work who prefer to
 follow the default global-use coding standards.
 > > Meaning we need to allow this only for the folder names to follow the
 correct PSR-4 Autoloaders standard
 >
 > If you want to use PSR-4 autoloaders and namespaces in your plugin, you
 can already do so just fine. The capitalization of the plugin folder
 doesn't matter for that.
 No, you can't.
 By following SOLID MVC, PSR-2 & PSR-4, you have to have:

 For the file, name as "/plugin/GreatMVC/Models/Item/ItemsObserver.php",
 you have to have a starting line of:
 {{{#!php
 <?php
 namespace GreatMVC/Models/Item;

 final class ItemsObserver
 {
 ....
 }
 }}}

 And when you do have Interfaces, Traits, Inherited classes, and you do run
 a REFACTOR in PHPStorm IDE, it will rename all the files correctly and
 automatically if this will follow this pattern. Otherwise it will break.
 Also the HACK won't work if you parse a namespace from "solid-mvc-tests"
 to "S-O-L-I-D---M-V-C---TESTS" as it sould be "SOLID_MVC_Tests", so the
 hack would have issues as well, and would work for simple names, and you
 CAN'T MAKE a pattern with IF ELSE if exact plugin names, as that sould be
 independent autoloader class file.
 And DASHES are NOT ALLOWED by PHP in namespaces.
 Regarding the CamelCase, again it has to follow the standard, and by the
 standart, it shoud have classes like:
 **AbstractElement.php** for **abstract class AbstractElement**
 **ElementIterface.php** for **interface Element**
 **DailyPricingTrait.php** for **trait DailyPricing**
 **Item.php** for **final class Item**.
 So everything is connected, and everything works and there is 10,000+
 plugins made already on S.O.L.I.D. MVC in Envato and GitHub and elsewhere
 where your download will be i.e. "EnvatoToolkit.zip" and not "envato-
 toolkit.zip". Also if the theme overrides extension view (html templates
 and assets) it has to match the plugin folder name, so if it matched in
 the begging with
 '/ThemeX/Extensions/GreatMVC/Templates/Admin/Item/AddEditItemForm.php'
 then it will BREAK working (the view will get back to default) after the
 plugin update if the plugin URL is in w.org, as it will reset the folder
 name of plugins to "great-m-v-c" and that is not a match of theme folder
 overridden extension folder name of "GreatMVC".

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/3692#comment:5>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org