[wp-hackers] Adding wp-includes/class folder
dragonwing at dragonu.net
Fri Aug 31 13:08:27 GMT 2007
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.
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.
> - --
> Peter Westwood
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers