Le 16/12/2021 à 05:01, Jordan LeDoux a écrit :
This is not a use case I highlighted because it's one that would be
difficult to support with this RFC. But as you say, it could be a good
future expansion. In particular, putting a query builder object into core
with some more advanced overloads built in may be the best way to
accomplish this, particularly if it is built with the idea in mind that the
entities themselves may also have overloads.
I can certainly add it to the future scope of this RFC however.
--
RE: The operator keyword and operator implementations being non-callable.
This was a limitation that I purposely placed on the operator keyword, as I
didn't like the idea of allowing syntax of the style `$obj->{'+'}();` or
`$obj->$op();` and I wanted developers to clearly understand that they
shouldn't treat these as normal methods in the vast majority of
circumstances. However, it seems this is one of the largest sticking points
for those who would otherwise support the RFC. To that end, I'm considering
removing that restriction on the `operator` keyword. If I were to do that,
you'd no longer need to wrap the operator in a closure to call it, though
the parser would still have problems with `$obj->+(...);`
I suppose my question then would be, is this an acceptable compromise on
the operator keyword? It removes one of the more annoying hurdles that
Danack mentioned and that others have pointed out, but retains much of the
benefits of the keyword that I expressed in my last email.
Jordan
Hello,
I'm not an internals hacker nor someone who can vote, but here is my
opinion about operator overloading: I don't like it. Nevertheless, if it
has to be done, I'd like it to be less challenging for PHP newcomers or
everyday developers.
An operator is not much more than a function shortcut, gmp examples
prove that point quite well. I don't see why it is necessary to create a
new syntax. It seems in the discussion that the magic method ship has
sailed, but I'd much prefer it.
I don't see why a user wouldn't be able to call an operator
method/function outside of the operator context. It has a signature:
left operand and right operand are its parameters, and it has a return
type. The engine internally will just call this function as userland
code could do.
I think that adding a new syntax for it, and allowing weird function
names which are the operator symbols will probably create some mind fuck
in people's mind when reading the code. I like things being simple, and
I'd love operator overloads to be simple functions, no more no less, not
"a new thing". The more PHP syntax grows the more complex it is to learn
and read.
Regarding the naming debate about operator names being different
depending upon the context, I agree, but I don't care, if operators have
a name in the engine, I'd prefer methods to carry the same name even if
it yields a different name in the domain semantics of the object: if you
are the low level operator function developer, you know what you are
doing furthermore you can still comment code. If you're the end user,
you will read the domain API documentation, not the code itself in many
cases.
If the names are a problem, why not registering those using an attribute
? If I remember well it was mentioned somewhere in the mail thread, it
would provide a way to explicitly register any method, with any name, as
being an operator implementation, sus userland could keep both syntax
and use the one they wish (i.e. $newNumber = $number->add($otherNumber);
or $newNumber = $number + $otherNumber. It's not insane to keep this
possibility open, on the contrary, it'd leverage the fact that operator
overloading in some context is just a shiny eye candy way of writing
some domain function shortcut.
That's my opinion and I don't if it worth a penny, but in my mind, an
operator is a function, and there's no reason that it'd be a different
thing.
Regards,
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
