Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.187 cause and error)
Message-ID: <50EE704F.8060100@lsces.co.uk>
Date: Thu, 10 Jan 2013 07:39:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CAAyV7nEWD7SYjjN_kia9rSknjL2BKi157G1r5VJPfTkHB4Y5ww@mail.gmail.com> <CAPaKmRn1w2k9O24j29SUFxO5KuWf6UWE1aZZ_urZyiroi_NfxA@mail.gmail.com> <CAAyV7nHafth_86-t+z1d=m6=8Pspewniz+pdYFBEjyjhrWt-FQ@mail.gmail.com> <CADajX4Bib0Zk7v+pHw4ntUhHTmKbrrbmGehbJuogujyOZ=Ce9w@mail.gmail.com> <CABo032FEnizYOB4qTHdytsJpadR2o1hcHwvfvBLnd0aLoskLVQ@mail.gmail.com> <CADajX4BdqodBwbs7YmN8dFOP_g+mXrN80uJD=xFVF_q4H-4WgA@mail.gmail.com> <CABo032Ed2b5AU_Ytj5y9xW5=STYR_0Lg6TL5r+thAYBm2ryuxQ@mail.gmail.com> <CAFp73XtVeKUYYYEcFnVf-=23h3bT3Y5opaX7VQHo-ru0RGzYEA@mail.gmail.com>
In-Reply-To: <CAFp73XtVeKUYYYEcFnVf-=23h3bT3Y5opaX7VQHo-ru0RGzYEA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
From: lester@lsces.co.uk (Lester Caine)

guilhermeblanco@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