Re: beginning plannings for PEAR for PHP6

Lukas Kahwe Smith wrote:
> 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.
>
> The problem is that right now we need to think about users with and
> without an opcode cache. If APC is bundled with PHP6, which seems
> likely at this point, this situation will slant towards opcode cache
> enabled. However, people running on hosters may till find that their
> available memory is too limited (or that APC is even disabled because
> of this). 
Hi,

I think I have the solution.  My original proposal will only call
__autoload() if the classes do not already exist.

Users like Rasmus, who wish to load everything up-front can do so:

<?php
require 'MDB2.php';
require 'MDB2/Driver/mysqli.php';
require 'MDB2/Module/Extended.php';
...
?>

other users who simply want ease and simplicity can do:

<?php
require 'PEAR/Autoload.php';
?>

In both cases, PEAR will be flexible enough to support either
development model, something that is impossible with the current
mandated require_once() CS rules.

Any further comment on this?  Rasmus, am I right or missing something else?

Thanks,
Greg