guilhermebla...@gmail.com wrote:
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.
I'd use the past tense there ...
And I'll get beaten around the head again.
PHP is a very nicely modular 'framework' on top of which many other views of the
world have now been built. We DON'T need to load a lot of the recent
developments ... we don't need to use them. Personally I don't load any MySQL
related extensions since I don't have MySQL loaded. APC is replaced by
eaccelerator which continues to work well for me (currently!). I've use
phpdocumentor since I started with PHP because that was what all of the
libraries USED internally to model/document the API, and since I used Eclipse as
my IDE for C/C++ code, PHPEclipse was a natural progression and also uses the
docblock information to provide in-line type hinting and a lot of the
information that people are now clamouring to build in to the 'language'?
I can understand some of the drives to 'new features', but I know I'm not alone
in feeling rail-roaded into having to accept changes that are just detracting
from writing code. Perhaps we can ignore 'e_strict' but the fundamental problem
doing that is that moving 5.2 based code to 5.5 is simply not practical. Setting
up a system that will run 5.2 code cleanly on a 5.4 configuration is only
practical if you have a completely different set-up for clean 5.4 code! We
NEEDED a better vision 5 years ago :( Now we need to manage the fallout and I
know I keep banging on about it, but over 50% of user land are STILL using 5.2!
Only 1.8% have 5.4 running with the main movement over the last few months TO
5.3 simply because that is the easiest way for ISP's to support their customers.
( http://w3techs.com/technologies/details/pl-php/5/all )
Bolting more and more facilities into core because a few users have the backing
to force them in does not help the vast majority of user-land users who don't
need those facilities. The argument that they need to be in the core so that
ISP's will provide them probably highlights the whole problem? If your
application needs some particular 'extension' to work then shouldn't that be
part of the 'application' rather than the 'infrastructure'? Isn't the fact that
one can add to PHP your own view of the world the whole point here. However it's
also the Achilles heel so there ARE now large groups of people 'doing their own
thing' and pulling things in a lot of different ways? Not everybody wants the
Symphony/Doctrine/ORM view of the world. We are happy with using the database
engine as the persistence layer, and a good abstraction layer as the interface
... code written 10 years ago still works ... or should do :(
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
