Am I the only one thinking PHP needs more stuff removed rather than added ?
Removing stuff from a programming language has virtually no benefit and a huge real economic cost. That, of course, is under the assumption that the programming language has users.
I could see them deprecating some stuff, and adding yet another E_EVEN_STRICTER level that tosses ugly notifications when deprecated things are done. That would be nice.
http://php.net/manual/en/errorfunc.constants.php
E_DEPRECATED - Run-time notices. Enable this to receive warnings about code that will not work in future versions. (Since PHP 5.3.0)
For example, PHP allows you to keep the name of a function in a variable and call it as if it were an anonymous function. So you can do something like:
$h = 'htmlspecialchars';
echo $h('<script>'); // <script>
Things get even more complicated when functions change in more subtle ways. If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects. If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.
A better solution is actually what PHP has been doing for the last few minor versions: deprecating stupid functions like mysql_real_escape_string() and encouraging people to migrate to modern alternatives. Once a function is marked as deprecated, it will be removed in a few years. This process takes longer, but it gives everyone enough time to update their own programs.
I see two possible cases, the choice between which can be made by the converter developers or by the user (maybe via command-line flags to the converter):
1) If the new functionality is intended to be a drop-in replacement (e.g. it fixes a security bug), no change is necessary.
2) If we want existing programs to keep using the old functionality, you could automatically translate all cases like this (assuming we're translating from PHP7 to PHP8):
echo $h('<script>'); // PHP7 code
echo php7_varcall($h, '<script>'); // PHP8 code
> If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects.
In general, any php7_builtin() should be implementable in PHP8 somehow. If that's not possible, I'd say there's a gross design error somewhere.
> If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.
In general, if the implementation of php7_builtin() in PHP8 relies on some library, then that library should be included in the "compatibility library" required to run all converted code.
Anyway, my point was that static analysis, which an upgrade script needs to perform, has serious limitations when it comes to dynamic features. Callable variables are a good example of this. What if there are 100 places in your codebase where a variable is callable, but only one of them is ever going to contain a deprecated function? Static analysis can't tell which one it is, because at runtime, the variables might come from anywhere: user input, a database, a command-line argument, or the phase of the moon. The only bulletproof solution is to convert them all to php7_varcall(), even the 99 variables that don't need upgrading. But then your code just becomes unreadable, and therefore even more unmaintainable than before.
I agree with your point that bulletproof conversion will make reflection-heavy code less readable. But still, if we can make a bulletproof converter that works on 100% of old code and leaves simple code relatively unchanged, doesn't that open up some nice options for everyone?
- Users who don't care about code quality, and just want their old code to work, will be happy because they will have a push-button upgrade solution.
- Users who care about code quality will also be happy, because they can run the converter and have a complete working program right away. Afterwards they can modernize it piece by piece, at their own pace, having a complete working program at each step. Without the converter they'd be stuck doing a full rewrite.
- Language implementors will be happy because they can keep the language clean as it evolves. Imagine how awesome Java could be today if they took this route.
However there is an elephant in the room with PHP, it has, quite frankly some terrible creations made by it. In much the same way MS had a whole bunch of technologies around DCOM and the like which suddenly found themselves disabled and strongly advised against use in XP SP2. I think PHP really does need to try and clean up its image.
The whole 'lets go find some sql injection vulns on github' game demonstrates many people still use the tool badly.
At what point does someone say, that they should re-design the tool, so that they encourage better use.
I'll be honest, if I hear someone say "we're using php for this" I assume its just because they are ignorant of other languages. I can't think of any problem I've been faced with, where PHP is the best solution.
So ultimately, if your going to try and remove stuff, why bother, you'll only break the existing projects, rather than improve them. The best thing is to treat the language as depreciated.
Sorry, but you obviously have not been taking notice over the past year or two. PHP really has been cleaning up its image. Go have a look at PHP-FIG, composer and packagist for starters.
Yes, there are problems. Yes, some/most may think that there are better solutions. But to think that PHP has not been "cleaning up its image" is just wrong.
I'll admit, I haven't really, because I'll turn it round, why would I?
We've seen Erlang start to be used quite a lot, Scala is becoming very interesting, and F# is appearing suitably mainstreme.
What features would make me think "hmm, I should check out what they are doing in PHP"?
Looking now I still see a cluttered array of APIs, some pretending they are C from the 80s, others hinting that they at least knew of objects in their design.
A quick look for static analysis rule systems for say our CI system: http://mark-story.com/posts/view/static-analysis-tools-for-p...
Wow, that's pretty poor.
What I do again see, are PHP developers who are not fluent in any other language. I always find that odd. For instance I've been doing mostly C# since version 2. But I would probably pass most Java or CamL interview questions anyone had. I am happy in C# knowing what I am missing from other languages (well, not happy, just its the right choice for the things I've been doing).
In short, PHP has an image problem with plenty of people. I am one of them. They can't easily solve it, without breaking a whole bunch of existing code, as most of my complaints are inherent languages features and core API design (or lack there off). I don't nock languages that eschew OO, but I do nock ones that implement it, just very, very badly.
Your definition of mainstream must differ from the dictionary's.
I have got the same two agents constantly bugging me "oh you know some Erlang right?" at the moment, but the only one that I begin to describe as mainstream is F#.
If your in any kind of LOB space which deals with 'Maths' F# is rampant now. Which is handy for me, as I used to instruct labs on OCaml at uni.
Just using www.inqjobs.co.uk looking in London for contract rates on 500pd+ I find over 20 roles for F#. Compare that to the Python or Ruby number.
That to me, is mainstream. Not quite Java/C++/C# league, but certainly out there.
As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase-out of the old one.
I would agree though that some features should not have been added in the first place. But they're in now, and once they are in they should probably stay in for a while.
You can remove things yourself? The PHP codebase is extremely modular. Just compile your own PHP and leave anything you don't want out. Has a wonderful --disable-all flag and then you just add the stuff you need.