On 4 November 2014 16:07, Lester Caine <les...@lsces.co.uk> wrote: > On 04/11/14 14:51, Kristopher wrote: > > Every IDE I've used has always working nicely with docblock > annotation > > and typing and has provided the facilities people seem to think > should > > be built in to PHP. > > > > You understand you don't have to use these new features, right? You can > > continue using comment-driven DocBlocks and not use any typing. They are > > purely optional features. > That argument falls flat on it's face when primary libraries upgrade to > use 'the new standards' at the expense of compatibility with previous > practices. Keeping compatible versions running just complicates matters > when the target infrastructure is changing daily :(
An 18 month release cycle for minors and over a decade since the last major is hardly "daily". You do not need to update the libraries when they start to use the new language features, but if you want to use the new library features, and those features leverage new language features, then you need to update the runtime as well. If you don't want/need the shiny new features, just don't upgrade. PHP is hardly the only ecosystem where this is true... > > To advocate not adding the features simply because you don't want them, > > when they are plenty of other people who do want them and do find a use > > for them, is pretty selfish. > Have I said ANYTHING about not fixing bug such as perhaps making PHP > work with Unicode properly? One man's bugfix is another man's feature. If you want one of the new shiny things you have to live with the other new shiny things that others want (and no-one is making you use any of these other things). > > > It's also pretty arrogant to assume your workflow and setup will work > > for everyone, and that they should just deal with it. > All I am saying is that many of the complaints being made by others that > PHP is missing 'important facilities' has a counter that in many cases > there is no problem if you use a different method of working. > > Some of us do perhaps need to document better the alternative way of > doing things, and I DO think that loading down the core engine with > facilities which are better provided by secondary tools is the wrong > approach. However since PHP has a modular structure, it should also be > possible to leave out components that are not essential to actually run > the code? > This almost precisely describes extensions, we already have this. But you cannot make *language* features (syntax etc) into extensions or it would be chaos and nothing would interoperate with anything. There *has* to be a stable base that everything can rely on. > It is perhaps just making a case for what is needed to improve the > functionality of the engine, and what - like the debuggers - can be kept > as non-essential secondary tools? > Both of these already are non-essential secondary tools. xdebug is an extension, which you do not have to install and isn't even bundled with PHP. phpdbg is an entirely new SAPI which you are free to ignore, none of the existing SAPIs rely on it in order to function, their functionality has not changed, it is a totally separate entry point. Even if we started bundling PHP with xdebug tomorrow, you need not ever use it if you don't want to, since absolutely nobody anywhere would start shipping PHP with xdebug compiled in as a static module, it would remain as a shared extension and you could simply disabled it. Likewise, if annotations existed, you could simply not use them if you didn't want any of the *new* functionality they would provide - they would not stop anything from working. > > -- > 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 > >
