On Wed, Dec 15, 2021 at 7:04 AM Dik Takken <dik.tak...@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
