Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Wed, Dec 15, 2021 at 7:04 AM Dik Takken wrote:
> Hi Jordan,
>
> Thanks a lot for your work on this RFC! I like the direction this is going.
>
> One thing that may be worthwhile looking into is the query builder use
> case. I mentioned it before:
>
> https://externals.io/message/115648#115771
>
> Basically it would enable using plain PHP expressions in stead of
> strings. So in stead of
>
> $query->where('product.price < ?1')->setParameter(1, 100);
>
> one could write:
>
> $query->where(Price < 100);
>
> Here Price is a class that represents a database column which has a
> (static) overload of the '<' operator. The operator overload yields an
> object representing a database expression, which gets passed to the
> where() method.
>
> In general I don't like this sort of clever construct which makes one
> wonder what on earth is going on. The reason I do like this particular
> use case is that it can simplify code and enable static analysis of
> query expressions.
>
> Now I'm not suggesting to support this creative use of operator
> overloading in the current RFC. It may however be useful to consider if
> this use case could be supported by a future RFC in a backward
> compatible way. Perhaps the RFC could mention it as a possible future
> extension.
>
> Kind regards,
> Dik Takken
>
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
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Wed, Dec 15, 2021, at 10:10 AM, Rowan Tommins wrote: > On 15/12/2021 15:03, Dik Takken wrote: >> $query->where(Price < 100); >> >> Here Price is a class that represents a database column which has a >> (static) overload of the '<' operator. The operator overload yields an >> object representing a database expression, which gets passed to the >> where() method. > > > The biggest problem with this particular example is not the operator > overloading, but the bare word "Price", which is currently a constant > lookup, not a class reference, as in: > > const Price = 50; > var_dump(Price < 100); > > > However, with any version of operator overloading that didn't limit the > return values of the overloaded operator, you could do something like: > > $query->where(Product::$price < 100) > > Where the static property Product::$price is an object which overloads > the "<" operator to return some kind of Condition object which can be > used by the query builder. Cool as that would be, it poses a problem as it would mean the Price object could either be directly compariable, or query-builder-comparable, but not both. There's no way to have multiple <=> overrides in different contexts. Also, for <=> in particular, that one is restricted to only return -1 | 0 | 1 anyway, so it wouldn't be able to return a query builder object. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On 15/12/2021 15:03, Dik Takken wrote: $query->where(Price < 100); Here Price is a class that represents a database column which has a (static) overload of the '<' operator. The operator overload yields an object representing a database expression, which gets passed to the where() method. The biggest problem with this particular example is not the operator overloading, but the bare word "Price", which is currently a constant lookup, not a class reference, as in: const Price = 50; var_dump(Price < 100); However, with any version of operator overloading that didn't limit the return values of the overloaded operator, you could do something like: $query->where(Product::$price < 100) Where the static property Product::$price is an object which overloads the "<" operator to return some kind of Condition object which can be used by the query builder. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On 09-12-2021 21:11, Jordan LeDoux wrote:
Hello internals,
I last brought this RFC up for discussion in August, and there was
certainly interesting discussion. Since then there have been many
improvements, and I'd like to re-open discussion on this RFC. I mentioned
in the first email to the list that I was planning on taking a while before
approaching a vote, however the RFC is much closer to vote-ready now, and
I'd like to open discussion with that in mind.
RFC Link: https://wiki.php.net/rfc/user_defined_operator_overloads
Hi Jordan,
Thanks a lot for your work on this RFC! I like the direction this is going.
One thing that may be worthwhile looking into is the query builder use
case. I mentioned it before:
https://externals.io/message/115648#115771
Basically it would enable using plain PHP expressions in stead of
strings. So in stead of
$query->where('product.price < ?1')->setParameter(1, 100);
one could write:
$query->where(Price < 100);
Here Price is a class that represents a database column which has a
(static) overload of the '<' operator. The operator overload yields an
object representing a database expression, which gets passed to the
where() method.
In general I don't like this sort of clever construct which makes one
wonder what on earth is going on. The reason I do like this particular
use case is that it can simplify code and enable static analysis of
query expressions.
Now I'm not suggesting to support this creative use of operator
overloading in the current RFC. It may however be useful to consider if
this use case could be supported by a future RFC in a backward
compatible way. Perhaps the RFC could mention it as a possible future
extension.
Kind regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Requesting RFC karma
On 15.12.2021 at 09:47, Oliver Nybroe wrote: > Hi, I would like to have RFC karma, so I can submit an RFC for a new syntax > for checking not instance of. RFC karma granted. Best of luck with the RFC! :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Requesting RFC karma
On 15.12.2021 at 09:47, Oliver Nybroe wrote: > Hi, I would like to have RFC karma, so I can submit an RFC for a new syntax > for checking not instance of. RFC karma granted. Best of luck with the RFC! :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Requesting RFC karma
Hi, I would like to have RFC karma, so I can submit an RFC for a new syntax for checking not instance of. Best regards Oliver Nybroe (he/him)
