Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117711
To: internals@lists.php.net
Date: Tue, 10 May 2022 19:31:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: en-US
References: <CAMrTa2FhEkhpDAyPR=6tt1M=F7SZRhh9RYydSO7p_Xv80X=Dfw@mail.gmail.com>
In-Reply-To: <CAMrTa2FhEkhpDAyPR=6tt1M=F7SZRhh9RYydSO7p_Xv80X=Dfw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: The future of objects and operators
From: tor.edvardsson@outlook.com (Tor Edvardsson)
Message-ID: <php.internals-117711@news.php.net>

Hi

> # 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

     $haystack->strpos($needle)

Nikic implemented a branch where he tested this

https://github.com/nikic/scalar_objects

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.

Tor