[wp-hackers] Adding wp-includes/class folder

[Jacob Santos]

I have patches, or a set patches for XMLRPC split. I'm planning on 
making a enhancement bug report, if most people are on board.

I took a look at the Tree implementation and thought that it was very 
interesting. The push for PHP 5 advantage is a longer goal. Lazy? Yes, 
but there is a reason it exists, and I forgot what the reason is, but 
okay. I don't use it, but I would like too.

I suggestion a convention that either we have all classes split up or we 
don't. I think dependency classes are great candidates for splits, 
because it allows me to focus on including just the file that I need. If 
included at the top, people can know which classes you are using below 
(mostly, my patches still use bootstrap that include everything, in 
order of the dependency. wp-includes/class/IXR.php includes everything 
in the IXR class namespace.

Jacob Santos

Peter Westwood wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jacob Santos wrote:
>   
>> What debate could there be for adding a class folder to wp-includes? I
>> know the current standard is to have 'class-whatever.php' file to
>> wp-includes folder. This would allow for better convention and
>> organization moving forward. I mean this for external developers.
>>
>>     
>
> I had been thinking just this over the past few days too!
> And I think it is a natural progression of the reorganisation of files
> that has happened in the past.
>
> It is a 2.4 item, and we will probably need to keep back-compat
> class-x.php files in wp-includes for at least one version as we may
> break some plugins.
>
>   
>> One disadvantage is that developers would have to browse through
>> multiple directories to find the current file. This setup is confusing
>> to beginners and well everyone that isn't intimate to the code. Another
>> disadvantage that using the PEAR convention you lose *perceived*
>> *initial* Opcode Caching speed boost.
>>
>> The advantages are
>>
>> 1. Easier to unit test, can remove classes from presentation files.
>> 2. Also keep the class model separate from application logic.
>> 3. Using the PEAR convention, you would be able to use __autoload() on
>> PHP 5.
>>     
>
> Ug. As a an OO developer usage of __autoload says lazy developer and
> harder to debug code - I much prefer the explicit list on includes than
> some magic. And the magic won't work on PHP4 which we support.
>
>   
>> 4. Easier to extend later (once the convention is established, any new
>> classes can be applied).
>> 5. Simplifies more root WordPress files.
>>
>> I suggest keeping the functions where they are and just separating the
>> classes into their own file, so you would have 1 class per file, instead
>> of cramming as many classes as there in that feature in a single file.
>> Using Dashes to represent folder paths, so wp_xmlrpc_server would be
>> /wp-includes/class/wp/xmlrpc/server.php. Would also suggestion using
>> Pascal naming convention for class names: WP_Xmlrpc_Server or ABSPATH .
>> WPINC . '/class/WP/Xmlrpc/Server.php'.
>>     
>
> I'm not sure a strict one class per file is needed.  For example I think
> it is worth keeping all the Walker classes together.  But some others
> should be split out into seperate files.
>
> westi
> - --
> Peter Westwood
> http://blog.ftwr.co.uk
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG17cYVPRdzag0AcURArTLAJ0XL7LZJMgnGhgqyPLQ9VPH6NZLEACgqjoW
> NFtjixSeeSBlkOZ6i+/UbHE=
> =9dSg
> -----END PGP SIGNATURE-----
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>