Anthony Ferrara wrote:
Since you asked me for feedback on how I would suggest improving the
RFC, so here it goes...
Silly question time ...
If I am reading all this correctly we are talking about how something is found
if I have not directly identified that I want to use it?
So if my base framework has already flagged which version of libraries I am
looking for I can continue to load them traditionally? Certainly identifying the
correct PEAR suit I want to work with has been important in the past as well as
the version of ADOdb and Smarty so identifying those on a target system that I
have less control over ... such as shared hosting! ... and supplying our own
bundle is only a necessary step if the required bundle is not available.
Although the safe way is to simply bundle everything anyway and not use
pre-loaded PEAR and the like.
Creating my own SPLClassLoader would be a way of implementing that if the
'default' one being offered is trying to load stuff that is not the correct
version? Or I just leave my own checks to find the correct versions depending on
which OS is running on the server?
require_once is almost essential in this case, and I was under the impression
that it was currently the economic way of checking that something was loaded
where the paths through libraries can get swapped? As usual there is much
pressure from a group of developers on why they have to have it, but no real
explanation on how it improves on the current methods? From my own view it is
accessing the correct PEAR classes which is the problem.
I have to admit that I simply 'switched off' since I could not see any point to
it and see it as just another esoteric noose rather than something I can see the
point of!
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
