Re: [PHP-DEV] [VOTE] Userspace operator overloading

This is only part of a thread. view whole thread
  109352
March 26, 2020 19:02 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
pon., 23 mar 2020 o 18:58 boehmer@gmx.de> napisał(a):

> Hi internals, > > I have opened voting on > https://wiki.php.net/rfc/userspace_operator_overloading, which allows > users > to overload operators in their own classes. >
I got two comments, a little late but always better than even later. The first thing is for operator methods when the operation is not supported I would see simply `return null;` as the right solution instead of constant, which name no one will remember. The second thing is notices which are confusing when suggesting to go and implement overloaded operator method on extension derived classes like stdClass like below: Notice: You have to implement the __add function in class stdClass to use this operator with an object in... The text of the notice is not documented in the RFC but it is implemented that way in the patch. A PHP developer is not likely gonna download the php-src source code, build environment and go with the ext/standard implementation and start adding it in C. The notice in this cases should either be different or not emitted at all. If the latter then that has to be documented I guess. Cheers, -- Michał Brzuchalski
  109384
March 28, 2020 13:13 ajf@ajf.me (Andrea Faulds)
Hi,

Michał Brzuchalski wrote:
> The first thing is for operator methods when the operation is not supported > I would see simply `return null;` as the right solution > instead of constant, which name no one will remember.
If we are to allow arbitrary use of operator overloading (rather than restricting it to specific kinds of use), which this RFC does, then IMHO we shouldn't special-case “null” — why can't it be a valid result of an overloaded operator? It is an arbitrary constraint on what can be done with operator overloading and makes the feature less generic. I would prefer if we used a different mechanism, for example a special subclass of Exception which will be caught internally by the operator overloading code, so that signalling an operation is unsupported can be “out of band” if that makes sense.
> The second thing is notices which are confusing when suggesting to go > and implement overloaded operator method on extension derived classes > like stdClass like below: > > Notice: You have to implement the __add function in class stdClass to use > this operator with an object in... > > The text of the notice is not documented in the RFC but it is implemented > that way in the patch.
Please document all notices your patch produces in the RFC, I think they are an important detail of the proposal.
> A PHP developer is not likely gonna download the php-src source code, > build environment and go with the ext/standard implementation and start > adding it in C. > The notice in this cases should either be different or not emitted at all. > If the latter then that has to be documented I guess.
That sounds reasonable, and it should be simple to add a check to your patch to make sure it won't show this message for internal/extension classes, right? By the way, if the operation has two operands, one of which is an internal/extension class and the other a user class, you could perhaps still show the mssage, but only mention the user class name. Regars, Andrea