What Are the Loopholes Still Left in PHP 7?

by Ahmed Khan  May 17, 2016

We contacted several PHP influencers and carried out a survey about the areas of PHP 7 that require improvements. We asked, “What do you think are the loopholes still left in PHP 7? Or what are the areas of improvements which should be covered in the next stable release, PHP 8?”

PHP 7 Community Survey

Below are the details of the survey:

Cal Evans, the Nomad PHP host and a very well known PHP influencer says:

“I am not sure I agree with the term “loopholes”. Yes, there are problems with PHP, there have been with every version and there will always be something. However, the core is usually good about fixing these issues in the next version. PHP 7 was a revolutionary leap forward for PHP, not just an evolutionary bump. As such, they will be fixing issues for the next few point releases. I look forward to a long and useful life for PHP 7 as our wonderful core developers work to stabilize it. I can’t wait to see what is coming next.”

William Hurley at quora says:

“At the moment PHP 7 does not have a JIT compiler. This will likely be added in a point release in the PHP 7 version. What is next for PHP 8? The only thing I’ve heard is some thought about including a native multi-threaded web server.”

iquito at Reddit says:

“Fixing the function names & also argument orders for some functions would be awesome. I have been programming in PHP for over 15 years, and some functions are just not named to be obvious or consistent, which leads to a lot of time spent with the manual sometimes.

Scalar objects could also solve this, but fixing the function names too would be nice.”

Hall_of_Famer at Reddit says:

I support property getters/setters too. The __get() magic method has many shortcomings, other than the one you mentioned above (as it can become a huge and long method). It’s also noticeable that PHP magic methods are very slow. I write all my getter and setter methods manually since if I choose magic methods, my application will be about 2 times slower. This is unacceptable for production environment/live application. Property getters/setters, if implemented properly, can not only provide cleaner syntax, but also improve the performance/overhead of magic methods.

Metrol at Reddit says:

“Declaring a return type in an interface of “self” should mean that the implementing class should also be able to declare a return type of “self” and simply return $this.

Real array objects. Move the 80 some odd array functions into the “soon to be deprecated” bin, and replace them with methods.

Remove ALL the database functions and focus all efforts on getting PDO as the only way to talk to a database. Allow class and global constants to be included into HEREDOC strings. Setter/Getter properties for class member variables. There’s an RFC that went nowhere, but I personally think is just brilliant.

Object literals like Javascript supports. In short, do what the array [] brackets do, but for an object with {} curlies. Old RFC on that one as well. Allow for multiple return values, like in Go.

Well, that’s just off the top of my head for a wish list.”

agiletoolkit at Reddit says:

Exceptions in __toString() should be permitted.

bwoebi  at Reddit says:

“As much as I wish to see that, as hard it is to make this work.

The main point about the fatal error is that is stops in the middle of the internal function, immediately. Exceptions would continue with a value like “” (empty string) and be only actually thrown when the function returns. [from an internal perspective.]”

Nanobot at Reddit says:

“Remove the mbstring.func_overload setting. This is a magic-quotes-level bad idea that can lead to all sorts of security issues and other problems if it’s enabled (and thus requires library/framework authors to do extra work to account for this possibility).

Bundle the mbstring module so it’s universally available. Seriously, the fact that we don’t have UTF-8 handling functions available out of the box in this day and age is embarrassing.

Change how mbstring handles invalid UTF-8 byte sequences to match the best practice recommendations in the current UTF-8 specification. That is, the longest valid prefix (or the first byte, whichever is longer) of an invalid sequence should be replaced with a single 0xfffd character, and parsing resumes with the next byte. This is potentially a security matter.

Array Key First Last Index please.

Add the ability to specify a locale ctype (or at least force ASCII) on the string case functions like strtolower and ctype_* functions, without having to change the locale of the whole process (which can cause problems on some servers). There are so many protocols, data formats, and other normalizations schemes that require just ASCII case normalization or ASCII character type validation, and there is currently no fully reliable way to do this efficiently. Making mbstring universally available would cover the case functions (because you can specify the character encoding), but not ctype.

Give me some functions for working with Unicode codepoints. I should at least be able to get the codepoint of the first character of a UTF-8 or UTF-16 string, and convert a codepoint into a UTF-8 or UTF-16 character. It would also be helpful to efficiently iterate through the characters of a UTF-8 string using a callback function, replacing invalid sequences with 0xfffd as it goes (unlike preg_replace_callback, which just commits sudoku when it encounters an invalid sequence).”

MorrisonLevi at Reddit says:

“Given that you are talking about PHP 8 (not 7.1) here is my short-list:

Unify the class symbol tables. Having first-class symbols can be really nice for some things. For instance, creating a closure from a method right looks roughly like this: [$class, ‘method’]. This is intuitive and prone to break during refactoring. If instead we could do $class->method it would solve both of those things. But right now it cannot be done because method could also be a property.

Deprecate the ability to call unset() on object properties that are defined in a class.

Deprecate (and remove?) bare strings.”

ThatWall at Reddit says:

Unicode, before anything else.

Hall_of_Famer at Reddit says:

“1. Async/Await: Cant imagine how many times I’ve mentioned it in PHP wishlist threads, hopefully it happens before PHP 8, say PHP 7.2 or 7.3?

  1. Scalar Objects: Already mentioned by someone else, no further need to explain.
  2. Object Literal: Similar to javascript syntax, ie. $obj = {name: $name, age: $age, gender: $gender};
  3. Remove function keyword from class methods: If return type is declared, move it between accessor modifier and method name, ie. public int sum(int $number, int $number2);
  4.    Generics: Many people want this one too, we can use generics for array and custom collection types.”

Huliek at Reddit says:

“Features I miss daily when programming in PHP:

  •      Universal function call syntax (ufcs)
  •      Getter, setters
  •      Const, immutable (for arguments, methods and properties)
  •      Multiple possibilities for type hints like Person|string
  •      Case-switch which also does pattern matching
  •      Value objects
  •      Arrow functions
  •      Operator overloading
  •      Friend classes
  •      Enum classes which can be type-hinted
  •      A whole bunch of iterators and array functions I’ve written myself”

jkon at daniweb says:

“This is a very theoretical question. PHP 7 is promising big surprises in later sub versions , so let’s see those first. PHP 7 isn’t as powerful as it was advertised. In many ways, things went the wrong way in my opinion (e.g. threads) in other aspects, it isn’t what PHP is “namespaces”. The problem is how PHP is used. There is a tendency in OOP languages to mix functional programming (Java lambdas were a clear sign), it may seem like moving backwards but it is just the reflex to extremely complex unnecessary code (of course programmers made that, and not OOP by itself). PHP is great at mixing programming paradigms. In PHP 7, you can see this backward injection of functional programming in whatever was OOP programming in PHP.

Of course all that (and not only in PHP) will create a very complex jungle with messy code. So I don’t know if it will be in PHP 8 or even if it will be PHP but the next big thing that I am waiting is a re examination of what OOP is with the motto “keep it as simple as possible” at the center.”

Conclusion:

This is what a few community members think about and expect from PHP 7’s upcoming versions. Since PHP is increasingly being used in web projects of all descriptions, it would be interesting to see the features in the upcoming versions of the language. We wish the very best of luck to PHP enthusiasts.

Test the performance of PHP 7 on optimized servers of renowned infrastructure providers on the Cloudways Managed PHP Hosting Platform. Launch your free trial now.

Create PHP websites without the worry of server management.

Deploy your PHP app on optimized PHP hosting servers.

About Ahmed Khan

Ahmed was a PHP community expert at Cloudways - A Managed PHP Hosting Cloud Platform. He is a software engineer with extensive knowledge in PHP and SEO. He loves watching Game of Thrones is his free time. Follow Ahmed on Twitter to stay updated with his works. You can email him at ahmed.khan@cloudways.com

Stay Connected:

You Might Also Like...

  • “Real array objects. Move the 80 some odd array functions into the “soon to be deprecated” bin, and replace them with methods.”

    Why? PHP is a functional language with OOP capabilities, when you replace everything with objects then you will start a war with the functional programmers.
    And yes functional programming has it’s place, just not for dependent contexts (where a class with constructor dependecy injection is much cleaner).

    Nanobot’s suggestion for mbstring is something I strongly support!

    “Remove ALL the database functions and focus all efforts on getting PDO as the only way to talk to a database. ”

    How about NO, at least not for the PostgreSQL extension which provides a much better support then PDO.
    When it comes to the MySQLi extension I can understand why, the only thing worse then MySQL is it’s API.

    “Case-switch which also does pattern matching”

    Yuck, no. Please, god the horror… and this already possible, use switch with true and use a condition in the case (n-path complexity everywhere).

    jkon’s comment is void, “Java lambdas were a clear sign” how is this in anyway a bad thing?? I have seen many use-cases where this has proven to be very usable.
    Oh wait its not the pure Java OOP as it once was, really? Bad programmers make bad coding, Closures/Lambdas are a very usable functionality, same goes for functional programming, if the language is to simple people will not make mistakes easy but will need to come-up with complex solutions for simple problems.