Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116652
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com>
In-Reply-To: <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com>
Date: Wed, 15 Dec 2021 20:01:50 -0800
Message-ID: <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com>
To: Dik Takken <dik.takken@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000028f32605d33b7ca2"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000028f32605d33b7ca2
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 15, 2021 at 7:04 AM Dik Takken <dik.takken@gmail.com> 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

--00000000000028f32605d33b7ca2--