Re: [RFC] User Defined Operator Overloads (v0.6)

From: Date: Thu, 16 Dec 2021 18:20:27 +0000
Subject: Re: [RFC] User Defined Operator Overloads (v0.6)
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-116656@lists.php.net to get a copy of this message
On Thu, 16 Dec 2021 at 12:21, Andreas Hennings <andreas@dqxtech.net> wrote:

> Methods and functions have searchable and clickable names. Operators don't.
> The "searchable" applies to grep searches in code, but also google

That's one of the reasons why I prefer a magic methods based approach.

function __plus(...){}

can be searched for...and for future scope, something like:

function __union(...){}

is more self-documenting (imo) than:

operator  ∪(...){}


> Lack of real parameter overloading
> Unlike C++ (or C?), we don't have real method/function overloading
> based on parameters.

Java is probably a better comparison language than C.

I have a note on the core problem that method overloading would face
for PHP here: https://phpopendocs.com/rfc_codex/method_overloading

But although they both involved the word 'overloading', operator
overloading, and method overloading are really separate features.

> we cannot have the conditional type hints.

btw you can just say 'types'.

Unlike some lesser languages, in PHP parameter types are enforced at
run-time; they aren't hints. I believe all references to hints (in
relation to types at least) have been removed from the PHP manual.

cheers
Dan
Ack


Thread (45 messages)

« previous php.internals (#116656) next »