# Overall Vision

Even though I'm just a PHP pleb I thought I give you my opinion on the
matter. If the following arguments is nothing but a repetition of what
is argued in the RFC or in previous discussions I apologize.

# Introduction

Historically I have been against operator overloading, however since
Jordan posted his first RFC on the subject I started to reevaluate my
position. What I realized is that I had just accepted the argument that
operator overloading creates unnecessary complexity, why? Because C++ has operator overloading and we all know that C++ is a very complex language and therefore it is an bad idea, however that argument is somewhat of fallacy.

Reevaluating operator overloading I came to the conclusion that many of the issues that has been discussed within the PHP community can be solved with operator overloading. What operator overloading enables us to do is to let the community to evolve the language without the formalities of the RFC process, it is a true decentralized governance, which is a good fit for a community based language like PHP.

Lets go over some of the recurring issues that has been discussed within the PHP community over the years. I assume here is what Larry specifies as object operators level 3 and optionally 4. I try to keep this as an high-level discussion to avoid any technical arguments regarding the PHP engine because that is outside of my expertise.

# Object primitives (scalar objects)

One recurring criticism against PHP is that it doesn't have methods attached to primitive types like other dynamic languages has, e.g.

    strpos($haystack, $needle)

instead of


Nikic implemented a branch where he tested this


With operator overloading we can implement this in user land and still use our object primitives together with normal primitives.

And it would also be possible to inherit these object primitives for custom object primitives, like an int range.

# Strict comparison

Another issue is that every comparison, except for strict equal, is a loose comparison with implicit type casting. If I remember correctly someone suggested that we could add another declare directive, similar to strict_types, to enable strict comparison per php file. With operator overloading there is no need to add another directive.

Assume the following

    (new Integer(3)) * 3 < $x

if the multiplication returns an Integer instance that is then used in the following comparison step, Integer can enforce strict typing and throw a TypeError on mismatch.

# Tainted input

Another issue is to handle tainted input, e.g. from query parameters, to avoid injection attacks when doing SQL queries. What I can see is that this is something that has been discussed for quite a long time. Currently there is no way for user land code to detect where a string originated from.

With operator overloading a framework could at least within the confines of the framework start to somewhat handle this issue.

Assume we have following two classes

    class SafeString
       // ...

    class UnsafeString
       // ...

Both implement the string append operator (.), on append both return the same type of instance as them selves except that appending with UnsafeString must always return UnsafeString. string literals could be assumed to be SafeString.

Now the framework could have these two functions

    function queryParam(string $name): UnsafeString;

    function executeSqlQuery(SafeString $query, array $params): int;

The GET queryParam() returns an UnsafeString that is incompatible with the $query argument for executeSqlQuery(). A programmer can still of course escape out to the standard library and avoid this, but it gives a least frameworks some tools to avoid the most common mistakes.

# Escaped output

Assume we could add a custom operator that is the echo operator (note this is not the same as _toString()). When doing PHP templating with <?= $foo ?> we could then automatically escape string objects.

# A new standard library

What all of these gives us is actually a new standard library driven by the community. It is an recurring theme to complain on the standard library, parameter order, function naming, lack of namespaces, not OOP etc. You all have heard it. But with operator overloading we give the community a chance to build something better without breaking the current one.

And perhaps over the years the community has produced something good that could be merged into PHP.

Currently I think the standard library is one of the biggest weaknesses of PHP, it is not bad, it is actually quite good, but the packaging has a big negative effect, especially on newcomers. There is almost no benefit of cleaning up the current standard library by renaming functions and reordering parameters, that would only create havoc with minimal benefits, but unfortunately that also stops us from actually getting a better designed standard library.

Operator overloading could be a way out of this dilemma, where we can implement a new powerful standard library without breaking the past and at the same time offer more expressiveness.

# Conclusion

These are just a few things I have been thinking of the past months, I have not properly tested the feasibility of them, thus there may be some flaws in them, but you are free to comment on it. Thanks.


PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to