Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP 8.0 Brings Major (And Breaking) Changes to a 25-Year-Old Language (techrepublic.com) 85

Posted by EditorDavid from the hypertext-preprocessor dept.
"PHP version 8.0 has arrived, bringing with it a major update to the 25-year-old programming language..." writes Tech Republic.

New language features include the nullsafe operator and attributes (commonly known as annotations in other languages) to add metadata to classes — and more: The JIT compiler is designed to bring performance improvements to web applications by turning code into instructions for the CPU at runtime. Meanwhile, union types is a feature that allows data of more than one type to be held by a variable. Named arguments allow developers to assign values to a function by specifying the value name, allowing optional parameters to be ignored. Alongside these, version 8.0 of PHP brings optimizations and enhancements to the language's type system, syntax, error handling and consistency....

Commenting on PHP 8.0, PHP programmer and stitcher.io developer, Brent Roose, noted that the latest version of the language may require developers to review code for any breaking changes.
This discussion has been archived. No new comments can be posted.

PHP 8.0 Brings Major (And Breaking) Changes to a 25-Year-Old Language More

PHP 8.0 Brings Major (And Breaking) Changes to a 25-Year-Old Language

Comments Filter:

  • Incessant version changes (Score:5, Insightful)

    by Black-Adder-61 ( 5628236 ) on Saturday November 28, 2020 @02:00PM (#60773446)
    I've been traumatized by switching from Perl 4 to Perl 5 (yes, that reveals my age), with the switch from PHP 4 to PHP 5 and I even made a half hearted effort to switch from PHP5 to PHP7. With each new version, my old scripts were broken. The "PHP CPAN", as PEAR was advertised in the times of PHP4, is now all but abandoned. Many of its packages do not work with PHP5, even more of them were broken by PHP7. I had to replace PEAR HTML_Form by FORMR. It's hard to simple classes for forms, HTML elements and alike. Everything is in the "frameworks": Symfony, laravel, Zend and alike. I decided to abandon PHP completely and start with Python. PHP was a good idea, had a very simple syntax and a very rich set of functions. However, its incessant change, and ever more people abandoning the language have severely curtailed its usefulness. I am officially abandoning the ship, after writing two books on PHP.

    • Re:Incessant version changes (Score:5, Informative)

      by JustAnotherOldGuy ( 4145623 ) on Saturday November 28, 2020 @02:16PM (#60773516) Journal

      I've stuck with PHP for personal use but I don't use any of the extended features. I don't write OO code, just straight procedural code, no fancy shit, so versions 3, 4, 5, 6, and 7 were all more or less the same for me.

      • Yup, same here. Only big issues was the mysql vs mysqli vs pdo db connections and the 5->7 deprecation of mysql support (so mysqli or pdo only now). A few methods were deprecated but had replacements, etc.

      • Re: (Score:2)

        by trawg ( 308495 )

        Ditto. I have PHP code that I wrote 20 years ago which is largely unchanged and still running in Production on a few sites today. Just written in basic core PHP using no extensions, no composer, nothing.

        I have a personal application I made for managing my own photo management which is the only real code I've written in the last 5 years. It's not huge but again it's almost all hand-written code (I caved and used a couple of composer extensions for a few external things like Google Cloud Vision), but I'm cont

        • Ditto. I have PHP code that I wrote 20 years ago which is largely unchanged and still running in Production on a few sites today.

          Same here. I could probably throw the vast majority of my code on PHP 8 without much trouble, except maybe for a few of the functions that have been deprecated or fiddled with.

      • Re: (Score:1)

        by alo75 ( 3660311 )
        Same here. Trying to transform PHP in a Object Oriented Language was the dumbest thing I've ever seen. If you want to program in a such way there is a plenty of other languages to use out there.

        • Same here. Trying to transform PHP in a Object Oriented Language was the dumbest thing I've ever seen

          Exactly. Someone somewhere decided that if PHP was going to become popular then it would have to support all the OO shit that is a waste of time for 90% of the projects out there.

    • Re: (Score:2)

      by Tom ( 822 )

      from Perl 4 to Perl 5 (yes, that reveals my age), with the switch from PHP 4 to PHP 5 and I even made a half hearted effort to switch from PHP5 to PHP7

      5 to 7 was relatively painless.

      3 to 4 was hell. Especially the years that you were writing PHP4 code that anyway had to be backwards compatible to PHP3.

      I still like PHP for its rapid-development features. In no other language am I able to get a prototype website with something I want to try or show up and running in like one hour.

    • Re: (Score:3)

      by Rufty ( 37223 )

      I loved Perl 4. Perl 5, just nope; went Ruby instead. PHP4 to PHP5 wasn't much trauma, though.

    • And yet people keep bitching about C++ maintaining a high level of compatibility. You can't have it both ways...

    • Re:Incessant version changes (Score:5, Interesting)

      by nagora ( 177841 ) on Saturday November 28, 2020 @06:33PM (#60774340)

      I've been traumatized by switching from Perl 4 to Perl 5 (yes, that reveals my age), with the switch from PHP 4 to PHP 5 and I even made a half hearted effort to switch from PHP5 to PHP7. With each new version, my old scripts were broken.

      At least PHP makes it clear - from 7.4 to 8.0 is going to be a big step. In Python a step from 3.8.1 to 3.8.2 can break your whole world. If you don't want incessant change then Python is not the language for you.

      • Re: (Score:2)

        by trawg ( 308495 )

        At least PHP makes it clear - from 7.4 to 8.0 is going to be a big step. In Python a step from 3.8.1 to 3.8.2 can break your whole world. If you don't want incessant change then Python is not the language for you.

        Not to mention the v2 vs v3 Python shenanigans. We had some grad interns start last week and had to run them through why the build process was failing on their laptops even though they had "Python installed already and it worked in other projects". Fun times!

      • And what would that breaking change be, exactly?

      • That's comment about Python breakage is just false. Changes to a new minor version, shouldn't introduce any breakage change, and it would most likely be considered a regression if it happened.

        That said, I develop a (large) project in Python, and agree that the changes between major version (eg 3.7 -> 3.8) is still too large sometimes. In general, they try to make all previous syntax working the same. However, with the introductions of new features, it sometimes breaks old programs. For instance, in v3.7

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      WOW! I get freakin' mad when people start whining about shortcomings of this and that. OMG, in 25 years I've learn ANY language has a lot of problems, including Python (obviously hadn't ported libraries from Python 2 to 3, try Wikipedia: "Python 2.7's end-of-life date was initially set at 2015 then postponed to 2020 out of concern that a large body of existing code could not easily be forward-ported to Python 3."). That's a 5(!!!) years delay! Well, here Java rules!

      Saying you abandon a programming language

      • Yuck. It takes a good year to learn Drupal. Meanwhile the client wants the work finished right away. I refuse to learn it as I will be fired before I figured out how it works.

        Meanwhile I can finish what I need outside a cms framework in a more modern language

    • Re:Incessant version changes (Score:4, Insightful)

      by yassa2020 ( 6703044 ) on Saturday November 28, 2020 @06:48PM (#60774374)

      I've been using PHP since the first public release in the mid 90's (yes, that reveals my age), and I skipped over the "object model" in PHP4 because it was so obviously dumb. IIRC that was an experiment that only lasted a couple of years anyway. Anyone who adopted PHP4 and their stuff broke in PHP5 clearly did not know how to write code well, because it was obvious 4 was garbage even for PHP lovers. I didn't have any breakages from 5-7 and can't even fathom how you can screw that up.

      As for PEAR, it is/was rarely ever useful. Same with frameworks. If you rely on that stuff you are doing it wrong. You are either lazy or don't know how computers make use of your code. The thing about objec models and frameworks, similar to most C libraries in the 80's and 90's (showing my age again), is that they require you to adopt the world view and perspective of the author, which is often ill-suited to your project. Libraries (and subsequently frameworks), should reflect the world view of your team, and the projects you are working on. It is incorrect to do it the other way around and have your team/project adopt the world view of the library/framework,

      I had to replace PEAR HTML_Form by FORMR. It's hard to simple classes for forms, HTML elements and alike. Everything is in the "frameworks": Symfony, laravel, Zend and alike.

      This I have a hard time understanding. Why would you need any middleware for that at all? It is braindead simple with the superglobal $_POST vars and such. If you need more control, you should be writing a CGI or FCGI anyway.

      However, its incessant change, and ever more people abandoning the language have severely curtailed its usefulness.

      This again makes me think you are either a lazy coder or don't understand how computers make use of your code in the first place. You want everyone to do the detailed work while you just stack blocks. That's the wrong way to code and will always fail, no matter how cool your blocks are.

    • Re: Incessant version changes (Score:5, Interesting)

      by IpSo_ ( 21711 ) on Saturday November 28, 2020 @07:57PM (#60774486) Homepage Journal

      You are jumping ship from PHP because of the high burden of backwards compatibility changes to move to a language that put it's developers through one of the most burdensome version changes in any mainstream language, which 12 years later has not been fully "completed" and even described as a mistake by the lead developer himself? I'm referring of course to Python v2 to v3 shitshow.

      As a lead developer of a 17 year old enterprise class application written in PHP, major version upgrades have been a complete non-issue for us. While PHP has its warts, major version backwards compatibility is one place they have done a great job.

      Keep up the great work PHP code devs!

      • Re: (Score:1)

        by tokul ( 682258 )

        > major version backwards compatibility is one place they have done a great job.

        I guess sarcasm sign got lost somewhere or you don't consider htmlspecialchars function break a problem. Or changing default behavior on openssl libraries.

    • Re:Incessant version changes (Score:5, Informative)

      by ras ( 84108 ) <russell+slashdot ... rt DOT id DOT au> on Saturday November 28, 2020 @08:05PM (#60774504) Homepage

      You think you have it bad. Mostly, what they are doing turning $x = 0 + array('a'); from a warning to an error. I know, hearsay, right? How dare they turn completely broken code from a warning into a fatal error.

      But have a thought for your compatriots in Python land. In Python2 x = '/a/filename'; if x[0] == '/': y = 1 sets y to 1 as you might expect if you know strings in python are just anther form of sequence, and indexing into a sequence does the obvious thing.

      Now lets move onto Python3. In Python3 even the assignment x = '/a/filename' contains a hidden trap. Strings in Python3 must be valid Unicode sequences, and as it happens not all 'nix file names are valid Unicode, so you really have to represent them as bytes even though it isn't necessary in this case. No problem you think, I'll just write: x =b'/a/filename'; if x[0] ==b '/': y = 1 but no, you've just fallen into the next trap, an indexing into bytes does not return a byte, it returns an int and so the if test now always fails, as does a lot of code that used to work and would be perfectly valid in most other languages, even strongly types ones. But unlike a strongly types language, these Python3 versions just fail silently, insidiously, without any hint or warning the code isn't doing what you might expect.

      This is not a case of making obviously incorrect code that could never worked fail, it actually turns perfectly clear and working code into bugs. Turns out it produces zillions of them.

      • In Python2 x = '/a/filename'; if x[0] == '/': y = 1 sets y to 1 as you might expect if you know strings in python are just anther form of sequence, and indexing into a sequence does the obvious thing.

        Now lets move onto Python3.

        I just ran your code in Python 3 (3.8.5), and it set y to 1. So what exactly is your complaint?

    • I have a site that was written back in 2001 (internal, backend only) when file extensions were still "php3." It used a very rudimentary template library that I randomly found somewhere on the net at the time--literally one file and less than 1,000 lines of code. The last update to this library was in 2002. It runs just fine with PHP8 and I've only had to make two changes in 18 years to replace a few deprecated but still functional things.

      One change was renaming the template class constructor to __construct(

    • Re: (Score:1)

      by dilly58 ( 541366 )
      Over the years, PHP has done a more-than-admirable job of mitigating backward compatibility (BC) where possible and documenting everything else really well. If you look at the current PHP-8.0.0 BC page on their website you'll see very detailed description of what breaks. Often times, the changes required that break BC are a result of earlier mistakes that are now being corrected after years of warnings. The other area PHP excels at is documentation. I've had very little code actually break at upgrade time.

  • following in the spirit of python and breaking all old code?

    • It seems to...

    • Re:Are they (Score:5, Insightful)

      by Joce640k ( 829181 ) on Saturday November 28, 2020 @02:20PM (#60773538) Homepage

      The best part is that all the errors will only appear at runtime (or should that be called "funtime" from now on?).

      Meanwhile, union types is a feature that allows data of more than one type to be held by a variable.

      What we really wanted was variables that can only hold one type of data.

    • The full Monty.

    • No, although there are some breaking changes. Nothing too big, though.

    • Well, Python has had a major transition from 2 --> 3, when garbage collection was introduced. The most annoying part was dealing with the "print", which was a language statement in Python2 and is a function with Python3. The only major problem with Python remains the problem of the GIL lock and the memory management which is not thread safe. There is IronPython, a thread-safe implementation of Python 2 language, but CPython is rather lousy at working with threads because it needs a serializing interprete

    • Curiously enough, while I emphatically object to perfectly good languages breaking backwards compatibility, with PHP it always has made sense. PHP is an extremely utilitarian language with a crazy inner API for fixing real-world Web problems. The web changes, so does PHP. Developing is PHP is so trivial that refactoring is trivial aswell. It usually takes only a few hours for even the largest PHP toolkits and apps to migrate to a new major version.

      Hence PHP breaking backwards compatibility isn't all that mu

  • "Meanwhile, union types is a feature that allows data of more than one type to be held by a variable."

    I admit to being an idiot and a mediocre programmer (at best), but this sounds like a *terrible* idea.

    Honestly, can someone explain why this is needed or why it's a "good" feature?

    • C has unions, they were needed to save RAM in the 1970s.

      It's good to see more modern languages thinking of efficiency instead of treating RAM as an infinite resource.

    • C has had it for decades.
      Very useful in low level programming when you want to assemble values from groups of bits.

    • Honestly, can someone explain why this is needed or why it's a "good" feature?

      How many times have you dealt with something than may have been one of several different things at different times? Never? Since that seems to be the only explanation for not seeing this as a good feature to have. Pretty much any language not rejected by practice and history has had this in one form or another (unions, algebraic sum types, subclassing, interfaces, etc. etc.), and those that didn't were forced to add it.

    • It is a fix to the leakkq
    • It is a fix to the missing feature of function overloading. You can have two functions with the same name accepting different parameters unfortunately

    • Variables have always been able to hold (and be assigned) all kinds of types in PHP.

      At some point optional types were introduced for parameters limiting them to a specific type. At that point, parameters in PHP could accept either any type or one specific type. This union type allows restricting the remaining 'any' parameters a bit more (requiring string|int is better than not requiring any type at all).

      I consider this as more of a transitional feature, with best practices probably stating that all paramete

    • Re: (Score:2)

      by Misagon ( 1135 )

      "Union type" is a terrible name IMHO. The way it works is more like a type restriction on a dynamically typed variable.

    • Re:What (Score:5, Informative)

      by dackroyd ( 468778 ) on Saturday November 28, 2020 @05:05PM (#60774108) Homepage

      The description you quoted is a poor description.

      A better one is that that union types are supported for parameter type declarations, return type declarations and property type declarations. The RFC is here: https://wiki.php.net/rfc/union... [php.net]

      The short version is that they make APIs easier to use. I wrote one example here, but there are other use-cases: https://en.reddit.com/r/PHP/co... [reddit.com]

      But they certainly aren't to be used everywhere.

    • Re:What (Score:4, Informative)

      by UnknownSoldier ( 67820 ) on Sunday November 29, 2020 @12:14AM (#60774912)

      It is a low-level optimization.

      It sometimes shows up in Space Partitioning [wikipedia.org] where you have a pointer to child nodes. With 64-bit CPUs it has fallen out of favor due to pointer "bloat" (8 bytes for pointers instead 4 bytes pointers on 32-bit CPUs). 32-bit offsets are now favored instead of wasting 8-bytes for a canonical pointer. i.e. See Andrei Alexandrescu's post on optimization [fb.com] where he mentions:

      * Prefer 64-bit code and 32-bit data.

      On x86 pointers can access byte-aligned data whereas other platforms pointers MUST be 4-byte, etc., aligned else you get a hardware trap. This means you can stuff meta-data into the X bottom bits of a pointer about child/leaf nodes. i.e. You can see data packing in Efficient Sparse Voxel Octrees [nvidia.com]

      C's union makes this rather trivial.

  • Does a programmer still need this to work out equality in PHP, FFS ?

    https://whydoesitsuck.com/why-... [whydoesitsuck.com]

  • Before PHP 8, sorting algorithms were unstable. This means that the order of equal elements wasn't guaranteed. PHP 8 changes the behaviour of all sorting functions to stable sorting.

    Also, was the ternary operator evaluation order ever fixed?

    • The 'wrong' (or probably more accurately, stupid) associativity is no longer allowed, since PHP 7.4: https://wiki.php.net/rfc/terna... [php.net]

      At some point the 'correct' (or more accurately, what people expect from other languages) might be supported. Currently you need to use () to avoid ambiguous associativity.

  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Saturday November 28, 2020 @06:07PM (#60774274)
    Comment removed based on user account deletion

    • 2. It is easy to deploy. On simple LAMP servers that cost a few dollars per month to host.

      3. It was extremely ugly, but is not actually that much worse than other languages that lack static typing. Just another programming language.

      4. It is not obvious what alternatives to use. Heavy weight Java? Windows mainly .Net? Error prone and hard work C++? JavaScript and Python are much the same as PHP.

  • PHP: A bad choice for startups and programmers (Score:3, Interesting)

    by greytree ( 7124971 ) on Saturday November 28, 2020 @06:12PM (#60774296)

    https://medium.com/@vinaykumar... [medium.com]

  • PHP is my first choice on Windows (Score:3)

    by Gabest ( 852807 ) on Sunday November 29, 2020 @03:45AM (#60775158)

    As a replacement for batch files. Too bad they broke PEAR around version 7, I still have to use 5 in old server code.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close