On Thu, 16 Dec 2021 at 19:20, Dan Ackroyd <dan...@basereality.com> wrote:
>
> On Thu, 16 Dec 2021 at 12:21, Andreas Hennings <andr...@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 ∪(...){}
>
I don't mind using magic methods for this, compared to an operator keyword.
It is also what I found is happening in python.
However, this does not give us searchability in the calling place,
only where it is declared / implemented.
>
> > 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.
I see the distinction in overloading based on the object type on the
left, vs overloading based on parameter types.
For a method call $a->f($b), the implementation of ->f() is chosen
based on the type of $a, but not $b.
For an operator call "$a + $b", with the system proposed here, again,
the implementation of "+" will be chosen based on the type of $a, but
not $b.
For native operator calls, the implementation is chosen based on the
types of $a and $b, but in general they are cast to the same type
before applying the operator.
For global function calls f($a, $b), the implementation is always the same.
In a language with parameter-based overloading, the implementation can
be chosen based on the types of $a and $b.
This brings me back to the "symmetry" concern.
In a call "$a->f($b)", it is very clear that the implementation is owned by $a.
However, in an operator expression "$a + $b", it looks as if both
sides are on equal footing, whereas in reality $a "owns" the
implementation.
Add to this that due to the weak typing and implicit casting,
developers could be completely misled by looking at an operator
invocation, if a value (in our case just the left side) has an
unexpected type in some edge cases.
Especially if it is not clear whether the value is a scalar or an object.
With a named method call, at least it is constrained to classes that
implement a method with that name.
>
> > 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.
Ok, what I mean is return type declarations.
In a class Matrix, operator(Matrix $other): Matrix {} can be declared
to always return Matrix, and operator(float $factor): float {} can be
declared to always return float.
However, with a generic operator(mixed $other): Matrix|float {}, we
cannot natively declare when the return value will be Matrix or float.
(a tool like psalm could still do it)
But even for parameters, if I just say "type" it won't be clear if I
mean the declared type on the parameter, or the actual type of the
argument value.
>
> cheers
> Dan
> Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
