Re: beginning plannings for PEAR for PHP6

Rasmus Lerdorf wrote:
> Gregory Beaver wrote:
>> Rasmus Lerdorf wrote:
>>> Justin Patrin wrote:
>>>> On 10/14/06, Gregory Beaver <greg@xxxxxxxxxxxxxxxxx> wrote:
>>>>> #2 libraries need to be opcode cache-friendly (require instead of
>>>>> require_once, or a class loader)
>>>>>
>>>> Could you explain more about this (or point us to some resources on
>>>> it)? This is the first I've heard of require_once not being ok to use.
>>>> Why in the world would using _once break an opcode cache?
>>>>
>>>> Ok, looking myself I found:
>>>> http://www.phpinsider.com/smarty-forum/viewtopic.php?t=7674&sid=a4a5feb6971f5dd4201d34aa6327d4d3
>>>>
>>>>
>>>> which links to a post by Rasmus explaining this somewhat:
>>>> http://marc.theaimsgroup.com/?l=php-dev&m=113883455711935&w=2
>>>> and a post to the lighttpd forum:
>>>> http://forum.lighttpd.net/topic/864
>>>>
>>>> Rasmus' message says he's looking into ways to fix this and tihs was
>>>> back in Feb. Perhaps he's fixed it by now? (I'm not subscribed to
>>>> php-internals, so...)
>>> We don't have a decent fix.  And it isn't that it breaks an opcode
>>> cache, just that it isn't very efficient because we end up with a
>>> useless open() syscall.  In general you are way better off declaring
>>> your dependencies up front and avoiding include spaghetti.  No matter
>>> what we do, if a script makes 5 calls to require_once on the same file
>>> that is always going to be way slower than a better organized
>>> application that makes a single call to require.  We should be
>>> encouraging the latter, not the former. 
>> Hi Rasmus,
>>
>> Since PEAR can't reliably load dependencies in libraries without some
>> kind of class loading, are you saying that you like the
>> autoload/class_exists('classname', true) solution I proposed, or that
>> something else would be better?
>
> I personally prefer completely clean libraries that don't do any
> runtime checks at all.  Any tricks you add will cause nasty
> performance penalties.  autoload is especially nasty because you are
> forcing things out of the compiler down into the executor which again
> kills performance under an opcode cache. 
Hi again,

For this solution, we would need to provide some easy way for them to
load all the needed dependencies.  One example could be to provide a
file like so:

<?php
// load required dependencies
require 'PEAR/Config.php';
require 'PEAR/Sqlite/Thingy.php';
?>

for packages like MDB2 that are complex, it would mean each driver would
supply this file, with the assumption that users would simply require it.

Unfortunately, this means end-user code would need to cut/paste
requirements.  This starts to get complicated, so I wonder if you have
any better ideas Rasmus.  The only other possibility that comes to mind
is writing a command for the "pear" command, something like:

pear generate-require MDB2 MDB2_Driver_mysqli PEAR_Config

which would spit out a conglomerate of all the required junk.

The obvious solution, of course, is relying more heavily on
documentation, which might be the best one.

Comments?

Greg