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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
