Why change require_once? A brief explanation of motives

Hi all,

I've been barely following the tremendously long thread on
the proposed
coding standard changes.  Needless to say, I wish that
people would
approach these from a perspective of assuming goodwill from
the PEAR
Group and the PEAR president, but I do understand that this
is a
difficult assumption to make, as one should be suspicious of
anyone in
power for good reasons.

I have extremely limited time to explain where these ideas
come from,
but let's just say that they come from many long hours and
many long
months of careful research.  First of all, anyone wishing to
know what
is planned for Pyrus, the installer for PEAR2 should check
two
locations, the source code at http://svn.pear.php.net
and the roadmap at
htt
p://pear.php.net/bugs/roadmap.php?package=PEAR

Here is a short list of things that are REALLY important to
understand:

1) EVERY existing PEAR package will continue to both install
and work,
but packages that use PEAR_Config or PEAR_Registry directly
will not
function properly.  Replacements will continue to work,
nothing is
changing here.  (P.S. haven't you all learned by now I'm a
BC freak?)

2) The suggested changes to usage of require_once in PEAR
packages are a
radical new idea and do require rational and careful
evalution.  I must
say I am extremely dissapointed with the response so far.  I
have to
encourage every person who has posted FUD without any
investigation to
in the future please try to back up any posted information
with facts,
or at the very least links to messages from the archives. 
Most
installer-related conversation is on the pear-corelists.php.net mailing
list, and I have been discussing these changes there for
over a year now.

As benchmarks have shown, and both Gopal and Rasmus have
blogged about,
require_once is a major problem for APC and other
optimization systems
because it forces several stat calls.  require_once with
relative path
makes this even more difficult.  On FreeBSD, for instance,
stat is a
very expensive system call, and can result in being a more
significant
bottleneck for PHP applications than database access.  Gopal
has blogged
extensively about APC and require_once at
http://t3.dotgnu.inf
o/blog/php/.  In addition, one of the huge problems
APC has encountered is with HTML_QuickForm's require_once
"loops" where
drivers require_once the base class, and everything is
loaded later,
requiring incredibly complex logic to resolve caching of
class
declarations at compile-time.  This is not to single out
HTML_QuickForm,
but instead to note that may PEAR packages are in fact the
source of an
unnecessary complexity that makes it almost impossible to
use an opcode
cache to improve the efficiency.

In addition, the use of require_once automatically limits
PEAR packages
to use on disk.  phar archives are required to modify the
source in
order to use the package, resulting in a significant
possibility of
accidental error introduction when post-processing the
source.

Finally, setting up include_path has proven again and again
to be a
major issue, and not just for beginners, as has been
asserted in many
(rather condescending) emails written in response.  I don't
think many
would consider me to be a beginner, but I regularly run
into
include_path issues with my development on the PEAR
installer.  Many
times, the installer finds itself accidentally including an
older
version of PEAR simply because the include_path is set up
incorrectly.
The same issue has affected my usage of Chiara_PEAR_Server
and many many
other scenarios.  include_path is not a bad thing, I happen
to love it,
but that doesn't mean I always want to rely upon it. 
Sometimes, when
setting up a "do-this-today" application, I'd
rather prototype something
that "just works" and then later properly set up
an include_path
environment, something that is physically impossible with
the current
PEAR library design.

The new coding standards are designed to eliminate these
problems all at
once.  There are two separate approaches to this:

Thing 1
=======
Eliminate require_once
1) use class names without loading the files containing
them
2) provide an autoload mechanism (PEAR2_Autoload)
3) provide a "it just works" file that can be
included to quickly use a
package (allfiles.php)

Thing 2
=======
Better document what is needed
1) use a graceful if (!class_exists('name', true)) for
reporting missing
dependencies
2) make sure all files needed are listed in the comments at
the top of
each file
3) add a README file to each package

Thing 2 is probably best done as a recommendation, although
#2 (document
dependencies) is a must-have.

Note that every PHP user is used to their own pet project's
methods, i.e.:

require_once 'Relative/Path.php';
require_once SOME_CONSTANT . 'Relative/Path.php';
Slow_Loader::Load('Classname');

As many benchmarks have shown, all of these are slower than
the simple
approach the standards recommend.  More importantly, they
are
inflexible.  The most common complaints about PEAR are (in
order)

1) you have to install things
2) you have to set up include_path
3) there's base classes required that are all non-PHP things
(PEAR and
PEAR_Error)
4) bloat

To eliminate #1, I have provided several things in the
installer, but
they do require that libraries make changes to the way
things work like
eliminating replacements.

For #2, The require_once requirement has to go.

#3 means we are never going to have another base class named
PEAR2 or
PEAR2_Loader - the inflexibility will make embedding PEAR2
libraries
harder than it is to embed PEAR libraries now.

Finally, #4 means we have to allow people to selectively
include
portions of a package, which the proposed solution does in
fact allow.

What is really involved for you all?  Change you code like
so:

<?php
require_once 'Another/Class.php';
class Blah extends Another_Class
{
}
?>

to this:

<?php
/**
 * This needs the Another_Class package, located at
http://pear.p
hp.net/pear2/Another_Class
 */
class Blah extends Another_Class
{
}
?>

note that I made up the URL, I have no idea what it will
actually look
like for PEAR2.

Users would simply need to either use allfiles.php,
autoload, or if
performance is an issue, they can do:

<?php
require '/full/path/to/Another/Class.php';
require '/full/path/to/Blah.php';
?>

and they are good to go, and can turn off APC stat and have
efficiency -
ALL interested parties win, use of PEAR skyrockets, and we
get a
crapload of new developers in the process to improve
things.

I am happy to discuss any of the proposals and change them,
but please
limit your comments to brief and carefully researched
comments, FUD is
extremely discouraging and does not help us solve the
problems at hand.

Thanks,
Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Greg, as I guess you haven't had to to read all the
messages
a) Performance of require once is _NOT_ a real issue, to put
it into 
your words "it is FUD!" ;)

- The statistics and analysis that Rasmus & co have done
is related to 
the final stage in a long process of optimizations. Notably
the key one 
prior to that would have been 'reducing the number of
includes'.
A simple example of which would be:
looking at included files for an application
- finding out why each file is loaded
- evaluating if it is needed or could be replaced
eg. if you only are using System::mkdir(), but pulling in
all of 
System.php. Then you can reduce a considerable amount of
code by not 
pulling it in and compiling it. (just write a simple
System:: lib and 
put it in your PEAR hacks file...

Libraries are inherently generic and always include more
code than is 
really needed for a specific usage. So the fact you can make
a 
relatively irrelevant  performance difference by moving
stuff like this 
around is one of the key reasons why performance  should not
be used in 
justifying this change.

In fact the use of require_once makes it considerably easier
to isolate 
'replaceable' parts. (As I have done in the past!), and
something that 
autoload will make a nightmare of.. -
eg. To find out  why class 'DB' is being loaded:
a) grep for require_once | grep DB
b) add some code to the autoloader that backtraces to find
out... (that 
only works if certain conditions are met!?)
c) grep for DB (and slowly go through references to MDB DB_*
etc..

Tick the one you would prefer!

Your other list of reasons are verging on FUD
- include_path is not a major issue. How many threads of
pear-general 
have you seen that end up saying "I can't use PEAR,
I've tried 
everything and it doesn't work!" - or have I missed
them? Actually I'm 
not sure I've ever seen any emails on that subject?  The
first line of 
my index.php basically fixes include paths for my
applications- It's 1 
line, and hardly an issue..

- PHAR usage, is, and never will be mainstream, it's an edge
case again. 
It's a kludge to work around a number of design and
implementation 
issues PHP has, almost trying to make something that PHP is
not... (a 
compiled language with .dll/.so type modules, or an exe
compiler..)  
While some may like it and use it, It's a very small
proportion of 
people downloading pear packages.

I would recommend you remove all the require_once  changes
(allfiles / 
autoload stuff) from the RFC, they are really the primary
contention 
with a few of us at least..

While we can all list common complaints about PEAR (like
annoying people 
posting long messages on mailing lists - me included ;) .. I
dont thing 
many of the ones you listed are hugely valid. (bloat, base
class, 
include_path,installing things..) -  most have work arounds
(except the 
base class).


Regards
Alan



Greg Beaver wrote:
> Hi all,
>
> I've been barely following the tremendously long thread
on the proposed
> coding standard changes.  Needless to say, I wish that
people would
> approach these from a perspective of assuming goodwill
from the PEAR
> Group and the PEAR president, but I do understand that
this is a
> difficult assumption to make, as one should be
suspicious of anyone in
> power for good reasons.
>
> I have extremely limited time to explain where these
ideas come from,
> but let's just say that they come from many long hours
and many long
> months of careful research.  First of all, anyone
wishing to know what
> is planned for Pyrus, the installer for PEAR2 should
check two
> locations, the source code at http://svn.pear.php.net
and the roadmap at
> htt
p://pear.php.net/bugs/roadmap.php?package=PEAR
>
> Here is a short list of things that are REALLY
important to understand:
>
> 1) EVERY existing PEAR package will continue to both
install and work,
> but packages that use PEAR_Config or PEAR_Registry
directly will not
> function properly.  Replacements will continue to work,
nothing is
> changing here.  (P.S. haven't you all learned by now
I'm a BC freak?)
>
> 2) The suggested changes to usage of require_once in
PEAR packages are a
> radical new idea and do require rational and careful
evalution.  I must
> say I am extremely dissapointed with the response so
far.  I have to
> encourage every person who has posted FUD without any
investigation to
> in the future please try to back up any posted
information with facts,
> or at the very least links to messages from the
archives.  Most
> installer-related conversation is on the pear-corelists.php.net mailing
> list, and I have been discussing these changes there
for over a year now.
>
> As benchmarks have shown, and both Gopal and Rasmus
have blogged about,
> require_once is a major problem for APC and other
optimization systems
> because it forces several stat calls.  require_once
with relative path
> makes this even more difficult.  On FreeBSD, for
instance, stat is a
> very expensive system call, and can result in being a
more significant
> bottleneck for PHP applications than database access. 
Gopal has blogged
> extensively about APC and require_once at
> http://t3.dotgnu.inf
o/blog/php/.  In addition, one of the huge problems
> APC has encountered is with HTML_QuickForm's
require_once "loops" where
> drivers require_once the base class, and everything is
loaded later,
> requiring incredibly complex logic to resolve caching
of class
> declarations at compile-time.  This is not to single
out HTML_QuickForm,
> but instead to note that may PEAR packages are in fact
the source of an
> unnecessary complexity that makes it almost impossible
to use an opcode
> cache to improve the efficiency.
>
> In addition, the use of require_once automatically
limits PEAR packages
> to use on disk.  phar archives are required to modify
the source in
> order to use the package, resulting in a significant
possibility of
> accidental error introduction when post-processing the
source.
>
> Finally, setting up include_path has proven again and
again to be a
> major issue, and not just for beginners, as has been
asserted in many
> (rather condescending) emails written in response.  I
don't think many
> would consider me to be a beginner, but I regularly run
into
> include_path issues with my development on the PEAR
installer.  Many
> times, the installer finds itself accidentally
including an older
> version of PEAR simply because the include_path is set
up incorrectly.
> The same issue has affected my usage of
Chiara_PEAR_Server and many many
> other scenarios.  include_path is not a bad thing, I
happen to love it,
> but that doesn't mean I always want to rely upon it. 
Sometimes, when
> setting up a "do-this-today" application, I'd
rather prototype something
> that "just works" and then later properly set
up an include_path
> environment, something that is physically impossible
with the current
> PEAR library design.
>
> The new coding standards are designed to eliminate
these problems all at
> once.  There are two separate approaches to this:
>
> Thing 1
> =======
> Eliminate require_once
> 1) use class names without loading the files containing
them
> 2) provide an autoload mechanism (PEAR2_Autoload)
> 3) provide a "it just works" file that can be
included to quickly use a
> package (allfiles.php)
>
> Thing 2
> =======
> Better document what is needed
> 1) use a graceful if (!class_exists('name', true)) for
reporting missing
> dependencies
> 2) make sure all files needed are listed in the
comments at the top of
> each file
> 3) add a README file to each package
>
> Thing 2 is probably best done as a recommendation,
although #2 (document
> dependencies) is a must-have.
>
> Note that every PHP user is used to their own pet
project's methods, i.e.:
>
> require_once 'Relative/Path.php';
> require_once SOME_CONSTANT . 'Relative/Path.php';
> Slow_Loader::Load('Classname');
>
> As many benchmarks have shown, all of these are slower
than the simple
> approach the standards recommend.  More importantly,
they are
> inflexible.  The most common complaints about PEAR are
(in order)
>
> 1) you have to install things
> 2) you have to set up include_path
> 3) there's base classes required that are all non-PHP
things (PEAR and
> PEAR_Error)
> 4) bloat
>
> To eliminate #1, I have provided several things in the
installer, but
> they do require that libraries make changes to the way
things work like
> eliminating replacements.
>
> For #2, The require_once requirement has to go.
>
> #3 means we are never going to have another base class
named PEAR2 or
> PEAR2_Loader - the inflexibility will make embedding
PEAR2 libraries
> harder than it is to embed PEAR libraries now.
>
> Finally, #4 means we have to allow people to
selectively include
> portions of a package, which the proposed solution does
in fact allow.
>
> What is really involved for you all?  Change you code
like so:
>
> <?php
> require_once 'Another/Class.php';
> class Blah extends Another_Class
> {
> }
> ?>
>
> to this:
>
> <?php
> /**
>  * This needs the Another_Class package, located at
> http://pear.p
hp.net/pear2/Another_Class
>  */
> class Blah extends Another_Class
> {
> }
> ?>
>
> note that I made up the URL, I have no idea what it
will actually look
> like for PEAR2.
>
> Users would simply need to either use allfiles.php,
autoload, or if
> performance is an issue, they can do:
>
> <?php
> require '/full/path/to/Another/Class.php';
> require '/full/path/to/Blah.php';
> ?>
>
> and they are good to go, and can turn off APC stat and
have efficiency -
> ALL interested parties win, use of PEAR skyrockets, and
we get a
> crapload of new developers in the process to improve
things.
>
> I am happy to discuss any of the proposals and change
them, but please
> limit your comments to brief and carefully researched
comments, FUD is
> extremely discouraging and does not help us solve the
problems at hand.
>
> Thanks,
> Greg
>
>   

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi Alan etc.

What are you arguing against?

Is having to define that __autoload() function really worth
not 
providing this flexibility?

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Greg Beaver wrote:
> I've been barely following the tremendously long thread
on the proposed
> coding standard changes.  Needless to say, I wish that
people would
> approach these from a perspective of assuming goodwill
from the PEAR
> Group and the PEAR president, but I do understand that
this is a
> difficult assumption to make, as one should be
suspicious of anyone in
> power for good reasons.

They also say that the road to hell is paved with good
intentions.

> 1) EVERY existing PEAR package will continue to both
install and work,
> but packages that use PEAR_Config or PEAR_Registry
directly will not
> function properly.  Replacements will continue to work,
nothing is
> changing here.  (P.S. haven't you all learned by now
I'm a BC freak?)

OK, so a question: will I be able to continue developing my
packages for the 
current standards and ignore all PEAR2 idiocy?

> 2) The suggested changes to usage of require_once in
PEAR packages are a
> radical new idea and do require rational and careful
evalution.  I must
> say I am extremely dissapointed with the response so
far.  I have to
> encourage every person who has posted FUD without any
investigation to
> in the future please try to back up any posted
information with facts,
> or at the very least links to messages from the
archives.  Most
> installer-related conversation is on the pear-corelists.php.net mailing
> list, and I have been discussing these changes there
for over a year now.
> 
> As benchmarks have shown, and both Gopal and Rasmus
have blogged about,
> require_once is a major problem for APC and other
optimization systems
> because it forces several stat calls.  require_once
with relative path
> makes this even more difficult.  On FreeBSD, for
instance, stat is a
> very expensive system call, and can result in being a
more significant
> bottleneck for PHP applications than database access. 
Gopal has blogged
> extensively about APC and require_once at
> http://t3.dotgnu.inf
o/blog/php/.  In addition, one of the huge problems
> APC has encountered is with HTML_QuickForm's
require_once "loops" where
> drivers require_once the base class, and everything is
loaded later,
> requiring incredibly complex logic to resolve caching
of class
> declarations at compile-time.  This is not to single
out HTML_QuickForm,
> but instead to note that may PEAR packages are in fact
the source of an
> unnecessary complexity that makes it almost impossible
to use an opcode
> cache to improve the efficiency.

That was very nice of you to provide a link to Gopal's blog,
since I immediately 
found an interesting post there, titled "include_once
mostly harmless":
http://t3.dotgnu.info/blog/php/include_once-most
ly-harmless.html

Quoting: "With the release of APC 3.0.14, there is a
decent workaround which 
doesn't require any changes to the php code."
"Essentially it converts all 
relative path includes, such as those from the pear paths,
into absolute path 
includes. This works well with the stat=0 mode because file
modifications are 
ignored after caching."

So, a question: where is an official benchmark of PEAR with
APC 3.0.14 with all 
relevant optimisations (apc.include_once_override on and
apc.stat off)? I only 
saw much handwaving and links to Rasmus's talk which was
given long before APC 
3.0.14

> In addition, the use of require_once automatically
limits PEAR packages
> to use on disk.  phar archives are required to modify
the source in
> order to use the package, resulting in a significant
possibility of
> accidental error introduction when post-processing the
source.

Building of a phar archive (if one is really needed, which I
doubt in most 
cases) is a job of a build tool.

> Finally, setting up include_path has proven again and
again to be a
> major issue, and not just for beginners, as has been
asserted in many
> (rather condescending) emails written in response.  I
don't think many
> would consider me to be a beginner, but I regularly run
into
> include_path issues with my development on the PEAR
installer.  Many
> times, the installer finds itself accidentally
including an older
> version of PEAR simply because the include_path is set
up incorrectly.
> The same issue has affected my usage of
Chiara_PEAR_Server and many many
> other scenarios.  include_path is not a bad thing, I
happen to love it,
> but that doesn't mean I always want to rely upon it. 
Sometimes, when
> setting up a "do-this-today" application, I'd
rather prototype something
> that "just works" and then later properly set
up an include_path
> environment, something that is physically impossible
with the current
> PEAR library design.

Greg, people who argued about include_path talked about
*using* PEAR packages, 
not *developing* them. Please do not try to shift the
discussion.

Of course you can have problems if you have several copies
of packages in 
various stages of completeness, but that's not the case for
99% of our users who 
only set up packages via PEAR installer.

That *will* be the problem for these users, BTW, if we allow
using the packages 
without installing them.


> The new coding standards are designed to eliminate
these problems all at
> once.  There are two separate approaches to this:
> 
> Thing 1
> =======
> Eliminate require_once
> 1) use class names without loading the files containing
them
> 2) provide an autoload mechanism (PEAR2_Autoload)
> 3) provide a "it just works" file that can be
included to quickly use a
> package (allfiles.php)
> 
> Thing 2
> =======
> Better document what is needed
> 1) use a graceful if (!class_exists('name', true)) for
reporting missing
> dependencies
> 2) make sure all files needed are listed in the
comments at the top of
> each file
> 3) add a README file to each package
> 
> Thing 2 is probably best done as a recommendation,
although #2 (document
> dependencies) is a must-have.
> 
> Note that every PHP user is used to their own pet
project's methods, i.e.:
> 
> require_once 'Relative/Path.php';
> require_once SOME_CONSTANT . 'Relative/Path.php';
> Slow_Loader::Load('Classname');
> 
> As many benchmarks have shown, all of these are slower
than the simple
> approach the standards recommend.  More importantly,
they are
> inflexible.  The most common complaints about PEAR are
(in order)

Where are results of these many benchmarks? As stated above,
I'd like to see 
these for APC 3.0.14 with all optimisations on.

Also your
Slow_Loader::Load('Classname');
is *the* most flexible, as it completely abstracts the
loading of class and does 
not require any "magic" like __autoload().


> 1) you have to install things

you'll have to manage dependencies manually

> 2) you have to set up include_path

you'll have to manage paths manually

> 3) there's base classes required that are all non-PHP
things (PEAR and
> PEAR_Error)

non-issue with E_STRICT packages. you'll need a
PEAR2_Autoload in PEAR2, though.

> 4) bloat

you do know yourself that it's mostly FUD, right? so why are
you repeating it here?

> What is really involved for you all?  Change you code
like so:
> 
> <?php
> require_once 'Another/Class.php';
> class Blah extends Another_Class
> {
> }
> ?>
> 
> to this:
> 
> <?php
> /**
>  * This needs the Another_Class package, located at
> http://pear.p
hp.net/pear2/Another_Class
>  */
> class Blah extends Another_Class
> {
> }
> ?>

So the people who are now unable to read error messages
thrown by PHP / PEAR 
will need to read freaking comments? Puh-lease!

> note that I made up the URL, I have no idea what it
will actually look
> like for PEAR2.
> 
> Users would simply need to either use allfiles.php,
autoload, or if
> performance is an issue, they can do:
> 
> <?php
> require '/full/path/to/Another/Class.php';
> require '/full/path/to/Blah.php';
> ?>

Why don't do this via installer, then?

pear_lib -> '/full/path/to/pear/'

Oh, yes, we are trying to reduce the number of replacements
and make people do 
everything manually.


> and they are good to go, and can turn off APC stat and
have efficiency -
> ALL interested parties win, use of PEAR skyrockets, and
we get a
> crapload of new developers in the process to improve
things.

And we get a crapload of developers who go the way of
PHPUnit, most likely. Some 
of them even manage packages with 6-figure downloads.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Lukas Kahwe Smith wrote:
> Hi Alan etc.
>
> What are you arguing against?
allfiles as a requirement, and any removal of require_once
from where 
they are supposed to be!
>
> Is having to define that __autoload() function really
worth not 
> providing this flexibility?
Yes - autoload make the code less clear, it makes optimizing
code more 
difficult as it becomes complex to properly analyze code.

I cant imagine how having a 'flexible' way to load a pear
file with code 
in it, would be a great asset.. -  Libraries are just
supposed to work, 
not 'might work if you havent broken your autoload code'

Regards
Alan

>
> regards,
> Lukas
>

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Lukas Kahwe Smith wrote:
> What are you arguing against?
> 
> Is having to define that __autoload() function really
worth not 
> providing this flexibility?

Failure to __autoload() a class always results in a fatal
error, exceptions 
thrown in __autoload() cannot be caught. You didn't provide
sample code Philippe 
asked you about [1] and I suppose that's because you simply
can't.

While you are busy writing that piece of code, I'd also like
to ask you to 
explain how we are expected to run unit tests on installed
PEAR2 packages, since 
they are not in the include_path anymore. Please provide
sample code, I know 
that you are very good at handwaving.

[1] http://news.ph
p.net/php.pear.dev/47529

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Greg Beaver schrieb:

> In addition, the use of require_once automatically
limits PEAR packages
> to use on disk.  phar archives are required to modify
the source in
> order to use the package, resulting in a significant
possibility of
> accidental error introduction when post-processing the
source.

i cannot understand this, i using PEAR a long time now,
installed or
shipped, i never had any problems with include_path ...

and would it not be easy to circumvent this by just using

include dirname(__FILE__) . '/somefile.php';
include dirname(__FILE__) . '/SubClass/Class.php';
include dirname(dirname(__FILE__)) . '/Pear.php';

??

sorry if i am totally wrong ...


> The new coding standards are designed to eliminate
these problems all at
> once.  There are two separate approaches to this:

at what cost?
including a huge amount of files not needed

if speed is the problem, why using OOP at all? 


> The most common complaints about PEAR are (in order)
> 
> 1) you have to install things
> 2) you have to set up include_path

^^ this depends on the package


> 3) there's base classes required that are all non-PHP
things (PEAR and
> PEAR_Error)

^^ depends an package too


> 4) bloat

^^ yes, hell, this will be fixed with allfiles.php ...


> Users would simply need to either use allfiles.php,
autoload, or if
> performance is an issue, they can do:
> 
> <?php
> require '/full/path/to/Another/Class.php';
> require '/full/path/to/Blah.php';
> ?>

what about if they just want to use it like they did it all
the time?

<?php
require 'MyPearClass.php';

// MyPearClass includes subclasses only if required
$MyPearSubClass = MyPearClass::factory('somesubclass');
?>

with your solution above, the user needs to decide what
classes he wants,
why complicate it this way?

for example in MDB2 currently you have to load about two
classes MDB2 and
the driver

with allfiles.php it will load at least 18 classes

18 classes, just for a simple database connection ...

18 classes in allfiles.php is faster than just two classes
with classic
require_once, using APC?



i just think that this is wrong approach to the problems
mentioned ...


-- 
Sebastian Mendel

www.sebastianmendel.de

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:
> Hi,
> 
> Lukas Kahwe Smith wrote:
>> What are you arguing against?
>>
>> Is having to define that __autoload() function
really worth not 
>> providing this flexibility?
> 
> Failure to __autoload() a class always results in a
fatal error, 
> exceptions thrown in __autoload() cannot be caught. You
didn't provide 
> sample code Philippe asked you about [1] and I suppose
that's because 
> you simply can't.

====== Bar.php =======
class Bar
{
   public static function factory($driver)
   {
     $class_name = 'Bar_'.$driver;
     if (__autoload($class_name)) {
       return new $class_name();
     }
     throw new Exception('unable to load');
   }
}

====== Bar/Meat.php =======
class Bar_Meat
{

}

====== foo.php =======
function __autoload($class_name)
{
   // if the user has some kind of preference about how to
confirm that 
the file
   // exists, or how syntax errors should be handled when
__autoload() 
is called
   // directly, then he could implement those here
   return include str_replace('_', '/',
$class_name).'.php';
}

$bar = Bar::factory('Meat');
var_dump(get_class($bar));

$bar = Bar::factory('Meaty');
var_dump(get_class($bar));

==========

This gives me the output:
Bar_Meat + 2 Warnings and an Exception

Now the "ugly" part in all of this, is something
we have been debating 
on this list before without a proper agreement. The first
one is the 
fact that in order to prevent those warnings, you would have
to suppress 
the include with an  or you would need to attempt to find the
file in 
the file system first, which is harder than one would hope
for when 
relying on the include_path, since internals does not think
we need an 
include_path search parameter in file_exists() like is
available in fopen().

The work arounds to this are either not truely reliable or
are 
inefficient and of course this is all open to race
conditions. The other 
issue are potential syntax errors in the file to be
included. The good 
news is that the user is now in control over how this should
be dealt 
with inside the __autoload(). The bad news is that the user
would need 
to implement all of this special handling for factory
loaders in the 
generic implementation that gets call in all other cases as
well, and 
there is no way to pass in any parameter to __autoload() to

differentiate explicit loading attempts compared to implicit
ones caused 
by making an instance of a not yet defined class.

In the end I again prefer the added flexibility, since
instead of all 
the back and forth in the past, where the PEAR developers
were 
essentially the ones deciding what hack to do, its now in
the 
application developers hands (though we can still provide
him with 
reliable implementations for this choice).

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:

> Is this the __autoload() as defined in user's code or
the __autoload() 
> defined in PEAR2_Load class, which, according to Greg,
we aren't providing:

This is the autoload as per the user .. see my updated
version I just 
send to the list.

>  > #3 means we are never going to have another base
class named PEAR2 or
>  > PEAR2_Loader - the inflexibility will make
embedding PEAR2 libraries
>  > harder than it is to embed PEAR libraries now.
> 
> ?
> 
> In any case, your much touted "flexibility"
is now mysteriously 
> vanishing, 'cause even if I use the glorious 
> allofthefilesthatidon'tneed.php approach, I still need
the __autoload() 
> defined.

I forgot to wrap things with a class_exists() call along the
lines as I 
explained in my pseudo code variant in response to
Philippe.

> Now please explain how I am expected to run unit tests
and usage 
> examples without mangling them.
> 
>> In the end I again prefer the added flexibility,
since instead of all 
>> the back and forth in the past, where the PEAR
developers were 
>> essentially the ones deciding what hack to do, its
now in the 
>> application developers hands (though we can still
provide him with 
>> reliable implementations for this choice).
> 
> And Greg tells us that we won't provide such
implementations. Whom 
> exactly must I believe here?

Alexey, I think you fail to understand that its not a black
and white 
world. Its not about "the RFC sucks" or if you
"believe" me or Greg. Its 
about finding a solution. Labeling things "idiocy"
or whatever serves no 
purpose to this list. It might give you personal
gratification.

I think we should provide various proven implementations for
users that 
provide different strategies.

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:

> Now please explain how I am expected to run unit tests
and usage 
> examples without mangling them.

oops .. wanted to reply to this statement as well. could you
elaborate 
about the problem you see?

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php