Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Hennings]

On Tue, 4 Jan 2022 at 03:23, Jordan LeDoux  wrote:
>
>
>
> On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings  wrote:
>>
>> To me it is not surprising that an RFC like this would be controversial.
>> We could enter a wonderful new era of value objects with operators,
>> but it is hard to envision that beforehand.
>>
>> The best might be to find and advertise with use cases and examples
>> from other languages.
>> (as mentioned, I don't really know where to start looking, otherwise I
>> would have already shared something)
>
>
> Oh, this was always going to be a controversial RFC. :) Operator overloading 
> is controversial in most languages, even the ones that have it and don't 
> really have problems because of it. It's the kind of feature that doesn't 
> affect most people most of the time, but that all developers end up having a 
> strong opinion about one way or another. I talked about that a little bit in 
> the internals podcast episode I did with Derick.
>
> NumPy is probably the absolute best example of this feature being used. NumPy 
> is an absolute killer feature of Python, and drives an enormous amount of the 
> development being done in the language. It could easily be pointed out that 
> NumPy is the equivalent of an extension however, being compiled down and 
> directly hooking into the Python language. NumPy is also not included in the 
> core Python language, though operator overloading *is*, importantly. However, 
> the toolchain for adding NumPy is much easier and consistent than the 
> toolchain for PHP extensions in general, and NumPy didn't have to add 
> overloads themselves as part of the extension (or teach Python devs the rules 
> around using them in general).
>
> So as another example, I'll pull up the math libraries in PHP. I maintain a 
> math library myself, but it isn't nearly as widely used as the works by Mark 
> Baker. The mathematical uses have been described here as "niche" and "small". 
> First let's see what Mark has to say about operator overloading (and this RFC 
> specifically):
>
> > Likewise, I have libraries for Matrix and Complex Numbers, where this would 
> > be an incredibly useful addition a similar RFC using magic was proposed 
> > 6 years ago, and sadly never made it :-( I hope this time it is accepted, 
> > especially as a new keyword feels better than magic
> - Source: https://twitter.com/Mark_Baker/status/1477957056464359427
>
> The libraries that Mark is referring to, markbaker/matrix and 
> markbaker/complex, have over 105 million installs combined on packagist. 
> (Source: https://packagist.org/?query=markbaker )
>
> > And so would `$lineValue = $unitPrice * $quantity;` work fine, with less 
> > words to read... and people who don't understand operator precedence would 
> > have problems with more complex mathematical formulae whether it was 
> > operator overloading or method name
> - Source: https://twitter.com/Mark_Baker/status/1478137583989309440
>
> > But why shouldn't it be `==`... these are valid use cases for a comparison; 
> > equally, vector additions ($vector1 + $vector2) are quite commonplace in 
> > mathematics
> - Source: https://twitter.com/Mark_Baker/status/1478131480383606787
>
> Marco's response to the person who maintains the literal largest complex 
> mathematics library in the entire language was:
>
> > Yeah, so use matlab?
>
> This is what I'm struggling with. I am seeing a lot of things here that sound 
> an awful lot like "that's not *my* use case, so no". That isn't how you 
> design the language. Nikita's objection to the syntax is much easier for me 
> to understand, because it is based on *language design*.
>
> Mathematics isn't something that is never used or never needed in PHP. The 
> idea that I need to justify this statement is somewhat alarming.

I fully agree:
Any language should aim at doing math well, natively.
You should not have to want to go to another language for
calculations. If this is the case, the language is incomplete.
And I think modern PHP aims to be or become a "complete" language.

If people currently don't use the language for math problems, this
says more about the language than about the people.
There is a potential here to enable new packages that solve new
problems, that people would have done in another language in the past.

>
> I have provided not only a multitude of examples of use cases in the RFC, but 
> I have repeatedly done so on this list as well. I have provided examples in 
> mathematics and examples in other domains, such as with Collections, with 
> userland scalar objects. I've mentioned possible future scope to expand 
> further into things like better support for query builders. I do not believe 
> the reason people vote no for this RFC is because they haven't been shown any 
> use cases. The use cases are self-apparent and have *also* been provided, 
> both within the current PHP ecosystem and outside of it. Both with existing 
> extensions and userland libraries.
>
> I 

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Jordan LeDoux]

On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings  wrote:

> To me it is not surprising that an RFC like this would be controversial.
> We could enter a wonderful new era of value objects with operators,
> but it is hard to envision that beforehand.
>
> The best might be to find and advertise with use cases and examples
> from other languages.
> (as mentioned, I don't really know where to start looking, otherwise I
> would have already shared something)
>

Oh, this was always going to be a controversial RFC. :) Operator
overloading is controversial in most languages, even the ones that have it
and don't really have problems because of it. It's the kind of feature that
doesn't affect most people most of the time, but that all developers end up
having a strong opinion about one way or another. I talked about that a
little bit in the internals podcast episode I did with Derick.

NumPy is probably the absolute best example of this feature being used.
NumPy is an absolute killer feature of Python, and drives an enormous
amount of the development being done in the language. It could easily be
pointed out that NumPy is the equivalent of an extension however, being
compiled down and directly hooking into the Python language. NumPy is also
not included in the core Python language, though operator overloading *is*,
importantly. However, the toolchain for adding NumPy is much easier and
consistent than the toolchain for PHP extensions in general, and NumPy
didn't have to add overloads themselves as part of the extension (or teach
Python devs the rules around using them in general).

So as another example, I'll pull up the math libraries in PHP. I maintain a
math library myself, but it isn't nearly as widely used as the works by
Mark Baker. The mathematical uses have been described here as "niche" and
"small". First let's see what Mark has to say about operator overloading
(and this RFC specifically):

> Likewise, I have libraries for Matrix and Complex Numbers, where this
would be an incredibly useful addition a similar RFC using magic was
proposed 6 years ago, and sadly never made it :-( I hope this time it is
accepted, especially as a new keyword feels better than magic
- Source: https://twitter.com/Mark_Baker/status/1477957056464359427

The libraries that Mark is referring to, markbaker/matrix and
markbaker/complex, have over 105 million installs combined on packagist.
(Source: https://packagist.org/?query=markbaker )

> And so would `$lineValue = $unitPrice * $quantity;` work fine, with less
words to read... and people who don't understand operator precedence would
have problems with more complex mathematical formulae whether it was
operator overloading or method name
- Source: https://twitter.com/Mark_Baker/status/1478137583989309440

> But why shouldn't it be `==`... these are valid use cases for a
comparison; equally, vector additions ($vector1 + $vector2) are quite
commonplace in mathematics
- Source: https://twitter.com/Mark_Baker/status/1478131480383606787

Marco's response to the person who maintains the literal largest complex
mathematics library in the entire language was:

> Yeah, so use matlab?

This is what I'm struggling with. I am seeing a lot of things here that
sound an awful lot like "that's not *my* use case, so no". That isn't how
you design the language. Nikita's objection to the syntax is much easier
for me to understand, because it is based on *language design*.

Mathematics isn't something that is never used or never needed in PHP. The
idea that I need to justify this statement is somewhat alarming.

I have provided not only a multitude of examples of use cases in the RFC,
but I have repeatedly done so on this list as well. I have provided
examples in mathematics and examples in other domains, such as with
Collections, with userland scalar objects. I've mentioned possible future
scope to expand further into things like better support for query builders.
I do not believe the reason people vote no for this RFC is because they
haven't been shown any use cases. The use cases are self-apparent and have
*also* been provided, both within the current PHP ecosystem and outside of
it. Both with existing extensions and userland libraries.

I sincerely hope that the reason someone votes no on this RFC isn't because
they think use cases don't exist or because the use cases are fringe. I
also hope that it's not because of "abuse", as this is a boogeyman that is
not supported by the ecosystems of nearly all languages with this feature.
The problem is that without those two objections, I'm left with few reasons
I could see to vote no, perhaps the most prominent being the one Nikita
raised with finding the syntax objectionable.

The syntax offers a lot for future scope in my opinion, some of it not even
related to operator overloads. It provides us a better way forward for
allowing objects to control casting, for instance. Many find the
__toString() implementation to be lacking. Controlled casting in C++ 

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Hennings]

On Mon, 3 Jan 2022 at 22:15, Jordan LeDoux  wrote:
>
> On Mon, Jan 3, 2022 at 9:07 AM Pierre  wrote:
>
> > I forgot to answer to that, specifically. I'd much more prefer to have
> > an explicit `equals(object $other): bool` (magic or not, really I do not
> > care) single method for equality only, that'd be great. In that sense, I
> > much preferred specific RFC about `__equalsTo()` or `__compareTo()`
> > alone that a huge generic operator overload RFC. I think both could
> > actually be separated, it wouldn't be that weird.
> >
>
> Based on the feedback so far, I am... concerned that doing so would leave
> the mathematical improvements out in the cold. It seems that a non-trivial
> number of voters do not see mathematics as a desirable use case on its own.
>
> There's not really anything preventing that part from being ripped out on
> its own, but the mathematical overloads add almost no complexity on their
> own to the patch. One of my main goals in contributing to PHP is to improve
> its usability and performance in mathematics.
>
> Using magic methods instead of the operator syntax would take perhaps 2
> hours to implement, it's a fairly trivial change in the scope of the RFC.
> However, I have no plans to bring this back in time for 8.2 should it be
> declined with a magic method implementation. Fundamentally, there are many
> voters that seem to be more concerned about possible abuse that empirically
> does not exist in most languages which have this feature, instead of
> improvements to one of the most neglected domains PHP is used in.
>
> And that's the real crux: *most* (but not all) of the objections raised so
> far suggest a future that factually does not exist in the example languages
> we can look at which already have this feature. C++ is perhaps the one real
> example of widespread abuse, however there are *multiple* aspects of this
> RFC which *specifically* target and discourage that kind of abuse.
> (Explicit typing of parameters, non-optional support for implied operators,
> restrictions on the return types of the == and <=> operators, errors and
> exceptions being propagated immediately, etc.)
>
> Further, the operand is not passed by-reference in this implementation,
> which flatly excludes many of the worst possible abuses.
>
> I understand all of these objections, but I do not agree with them.
> Obviously. If I did, then I wouldn't bring this RFC to a vote. What I have
> proposed is the most restricted version of operator overloads in any
> language I researched, and that is still not enough for many voters, some
> of whom have flatly stated that there is no version of this feature they
> would ever vote for. If that is the kind of headwind against quite
> fundamental improvements to mathematics within the language, then all of my
> energy will be required to produce any improvement at all, and I cannot
> spend effort on things which are unrelated.

To me it is not surprising that an RFC like this would be controversial.
We could enter a wonderful new era of value objects with operators,
but it is hard to envision that beforehand.

The best might be to find and advertise with use cases and examples
from other languages.
(as mentioned, I don't really know where to start looking, otherwise I
would have already shared something)

>
> Jordan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Hennings]

Hello Jordan,

I have another note about the RFC.
(I am not sure what's the policy, if we should continue _all_
discussion here or go back to the RFC thread. Hope it's ok here.)

OperandPosition::LeftSide
OperandPosition::RightSide

I wonder if this is the best way to model this.
Especially, it does not account for the case where an operator only
works in one direction, or the allowed operand type is dependent on
the direction.
E.g., (Money / float) is ok, but (float / Money) probably not supported.
Or if it is supported, then the return type will be quite different.
You can throw an exception, but this is not useful for static analysis.

An alternative syntax with a few more keywords:

abstract class Money {
  symmetric operator * (float|int $other): Money;  // Commutative.
  left operator / (float|int $other): Money;  // Only $a / $b allowed,
$b / $a not possible.
  left operator - (Money $other): Money;  // $a - $b
  right operator - (Money $other): Money;  // $b - $a
}

Btw, in the Matrix example from the RFC, under "When will $operandPos
be useful?", the $operandPos is not really useful, because it will
always pick the default $a - $b version.
The same applies to "-" operator in my Money example, because $other
already implements the operator.

The $operandPos is only needed if the left operand does _not_
implement the operator. Which is the case e.g. for complex numbers, or
the Number class from the RFC example.

I am trying to think of cases where ($a  $b) would have a
different type than ($b  $a), but I can't think of any.
Or rather, for any case that I could think of, the mirror operator
could simply be provided by $b.

I am not married to the modifier names, e.g. it could be "symmetric"
or "commutative" or something else.
For left/right perhaps I prefer to talk about the "default direction"
vs the "flipped direction", not sure how this could be turned into
keywords.
If we don't like more keywords, perhaps something like "!operator" for
the flipped version?

Cheers
Andreas

On Mon, 3 Jan 2022 at 01:14, Jordan LeDoux  wrote:
>
> Hello internals,
>
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
>
> To review past discussions on this RFC and the feature in general, please
> refer to:
>
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
>
> Jordan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Jordan LeDoux]

On Mon, Jan 3, 2022 at 9:07 AM Pierre  wrote:

> I forgot to answer to that, specifically. I'd much more prefer to have
> an explicit `equals(object $other): bool` (magic or not, really I do not
> care) single method for equality only, that'd be great. In that sense, I
> much preferred specific RFC about `__equalsTo()` or `__compareTo()`
> alone that a huge generic operator overload RFC. I think both could
> actually be separated, it wouldn't be that weird.
>

Based on the feedback so far, I am... concerned that doing so would leave
the mathematical improvements out in the cold. It seems that a non-trivial
number of voters do not see mathematics as a desirable use case on its own.

There's not really anything preventing that part from being ripped out on
its own, but the mathematical overloads add almost no complexity on their
own to the patch. One of my main goals in contributing to PHP is to improve
its usability and performance in mathematics.

Using magic methods instead of the operator syntax would take perhaps 2
hours to implement, it's a fairly trivial change in the scope of the RFC.
However, I have no plans to bring this back in time for 8.2 should it be
declined with a magic method implementation. Fundamentally, there are many
voters that seem to be more concerned about possible abuse that empirically
does not exist in most languages which have this feature, instead of
improvements to one of the most neglected domains PHP is used in.

And that's the real crux: *most* (but not all) of the objections raised so
far suggest a future that factually does not exist in the example languages
we can look at which already have this feature. C++ is perhaps the one real
example of widespread abuse, however there are *multiple* aspects of this
RFC which *specifically* target and discourage that kind of abuse.
(Explicit typing of parameters, non-optional support for implied operators,
restrictions on the return types of the == and <=> operators, errors and
exceptions being propagated immediately, etc.)

Further, the operand is not passed by-reference in this implementation,
which flatly excludes many of the worst possible abuses.

I understand all of these objections, but I do not agree with them.
Obviously. If I did, then I wouldn't bring this RFC to a vote. What I have
proposed is the most restricted version of operator overloads in any
language I researched, and that is still not enough for many voters, some
of whom have flatly stated that there is no version of this feature they
would ever vote for. If that is the kind of headwind against quite
fundamental improvements to mathematics within the language, then all of my
energy will be required to produce any improvement at all, and I cannot
spend effort on things which are unrelated.

Jordan

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Jan 4, 2022, 2:17 AM Pierre Joye  wrote:

>
>
> On Tue, Jan 4, 2022, 1:35 AM Horváth V.  wrote:
>
>> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>>  > Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
>>  > might be okayish, though.  ICU ships a VS solution file
>>  > (source/allinone/allinone.sln) which works fine.  I don't know
>>  > whether using that would be okay for Conan.
>>
>> No need to worry about that, it's just a way to coerce ICU's build
>> system into behaving well on Windows. Conan uses Msys2 as a build
>> environment for projects with *nix lock-in, which produces native
>> binaries without the cygwin shenanigans.
>>
>
> what does it mean exactly here?
>
> it uses msys for autoconf and co support but actually uses vc? or it
> relies on gcc and co?
>


rt*m :)

it can use whatever is needed and prioritization of cmd in the paths is
supported, neat  :)

https://docs.conan.io/en/latest/systems_cross_building/windows_subsystems.html

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Horváth V .]

On 2022. 01. 03. 20:17, Pierre Joye wrote:

it uses msys for autoconf and co support but actually uses vc?


Exactly.

Unless you have another compiler specified in your Conan profile. You 
can see in the _platform method that the dictionary is indexed with 
self.settings.os and self.settings.compiler, both of which come from the 
selected profile. Taking that into account, Windows + VS is supported. 
The value in the dictionary is just used to massage the existing ICU 
build system into emitting files that can be used to build with VS.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Jan 4, 2022, 1:35 AM Horváth V.  wrote:

> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>  > Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
>  > might be okayish, though.  ICU ships a VS solution file
>  > (source/allinone/allinone.sln) which works fine.  I don't know
>  > whether using that would be okay for Conan.
>
> No need to worry about that, it's just a way to coerce ICU's build
> system into behaving well on Windows. Conan uses Msys2 as a build
> environment for projects with *nix lock-in, which produces native
> binaries without the cygwin shenanigans.
>

what does it mean exactly here?

it uses msys for autoconf and co support but actually uses vc? or it relies
on gcc and co?

Re: [PHP-DEV] Surveying interest regarding CMake

[Horváth V .]

On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
> Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
> might be okayish, though.  ICU ships a VS solution file
> (source/allinone/allinone.sln) which works fine.  I don't know
> whether using that would be okay for Conan.

No need to worry about that, it's just a way to coerce ICU's build
system into behaving well on Windows. Conan uses Msys2 as a build
environment for projects with *nix lock-in, which produces native
binaries without the cygwin shenanigans.

> Also note that we're using a patched libffi[1]; since that patch is
> not complete, I didn't submit it upstream, but at least this basic
> __vectorcall support is important for ext/ffi.

That's a tough one. I see you commented on the issue regarding this:
https://github.com/libffi/libffi/issues/500#issuecomment-671037484

I'm not sure what should be done in this case. I have a feeling the
Conan team would not welcome such a partial feature patch. Maybe having
an Artifactory server on php.net, where a custom recipe is hosted would
solve this. I'm sure if the Conan team was contacted about this, then
they would be glad to help.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[David Gebler]

On Mon, Jan 3, 2022 at 5:38 PM Nikita Popov  wrote:

> On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux 
> wrote:
>
> > Hello internals,
> >
> > I've opened voting on
> > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting
> will
> > close on 2022-01-17.
> >
> > To review past discussions on this RFC and the feature in general, please
> > refer to:
> >
> > - https://externals.io/message/116611 | Current RFC discussion
> > - https://externals.io/message/115764 | Initial RFC discussion
> > - https://externals.io/message/115648 | Pre-RFC discussion and
> > fact-finding
> >
> > Jordan
> >
>
> Voted No on this one. I did support the previous proposal on this topic,
> but I don't like the changes that this iteration has introduced relative to
> the previous proposal.
>
> The part that I dislike most (and that I consider an exclusion criterion
> regardless of any other merits of the proposal) is the introduction of a
> new "operator +" style syntax. I found the motivation for this choice given
> in the RFC rather weak -- it seems to be a very speculative
> forward-compatibility argument, and I'm not sure it holds water even if we
> accept the premise.

There's nothing preventing us, from a technical
> point-of-view, from allowing the use of some keyword only with magic
> methods. On the other hand, the cost of this move is immediate: All tooling
> will have to deal with a new, special kind of method declaration.
>

I agree wholeheartedly with this. I don't have a vote but if I did I'd vote
no. I think if operator overloading is to be introduced, new magic methods
using names like __add and __equals are preferable for a number of reasons.


>
> I'm also not a fan of the OperandPosition approach, though I could probably
> live with it. The previous approach using static methods seemed more
> natural to me, especially when it comes to operators that do not typically
> commute (e.g. subtraction).
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Hennings]

On Mon, 3 Jan 2022 at 16:00, Marco Pivetta  wrote:
>
> Hey Andreas,
>
> On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings  wrote:
>>
>> I imagine that operator overloads can improve DX for these use cases,
>> but at a cost for the overall language.
>>
>> How would you (Marco) see the future of arithmetic libraries for time,
>> money etc without overloaded operators?
>> How would these calculations look like e.g. with infix functions?
>> Do you think this can eliminate the desire for operator overloads?
>>
>>
>> E.g. something like this?
>>
>> $ts0 = new Timestamp($seconds0);
>> $ts1 = new Timestamp($seconds1);
>> /** @var Duration $duration */
>> $duration = $ts1 - $ts0;  // Operator overload notation.
>> $duration = Duration::betweenTimestamps($ts0, $ts1);  // Static method 
>> notation.
>> $duration = $ts1->diff($ts0);  // Object method notation.
>> $duration = $ts0  $ts1  // Infix notation
>> based on static method.
>> $duration = $ts1  $ts0  // Infix notation based on object method.
>
>
> I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that 
> unreadable, and there is no need to abbreviate it to "diff" either.
> Whether it needs to be static methods or instance methods depends on the 
> wished API design.

Ok for "subtract", I should have thought of that :)
Although for me "subtract" sounds like a possibly mutable method,
whereas "diff" sounds immutable.

This said, I am not really convinced that the current syntax is "good enough".

>
> What this RFC aims at is a mathematical language, inside another general 
> purpose language: for complex expressions, I'd probably run it in a subsystem 
> dedicated to this instead.

For isolated "complex expressions", perhaps.

But we should think about algorithms with multiple small math
operations, e.g. a foreach with a repeated calculations, some of them
in conditional branches, e.g. to calculate prices, taxes, rent etc. In
all these operations, we want static analysis to check compatibility
of operands.

I think these algorithms will become more readable with overloaded
operators, while any "embedded formula engine" would make them vastly
more complex.

Btw others already pointed out that we also want comparison of value
objects, not just math.
But I came up with the math use cases, so am sticking to it to be fair.

Personally I still don't have a clear opinion for or against, but I
also don't have voting rights, so...

>
> See for example:
>
>  * https://en.wikipedia.org/wiki/Expression_(mathematics) (I'm literally just 
> picking a complex example - don't even know how to read that properly)
>  * and its textual representation in 
> https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)=edit=1
>
> ```php
> $expression = <<<'MATH'
> f(a)+\sum_{k=1}^n\left.\frac{1}{k!}\frac{d^k}{dt^k}\right|_{t=0}f(u(t)) + 
> \int_0^1 \frac{(1-t)^n }{n!} \frac{d^{n+1}}{dt^{n+1}} f(u(t))\, dt.
> MATH;
>
> $result = $userlandExpressionEngine->evaluate(
> $expression,
> [
>  // ... bind parameters here 
> ]
> );
> ```
>
> Heck, I can probably ask the `$userlandExpressionEngine` to render that 
> monstrosity for me (see attachment).
>
> Note that we do this stuff constantly for SQL, yet we haven't designed a 
> system for embedding SQL into the language,

Actually we do have query builders, to reduce the amount of literal
SQL strings in code, and to make it feel more "native".
And where we do have literal SQL, we have to be very careful not to
break things, especially when binding or escaping/encoding variables.

> and still, SQL is used many magnitudes more than all what was discussed in 
> this RFC.

This may be true currently, for the arithmetics use cases.
This said, the reason for a small amount of math libraries in PHP
(which I did not actually count) could be exactly because of a lack of
overloaded operators.
And I think timestamp calculations are already relevant enough in today's code.

It would be interesting to see how much overloaded operators are used
in Python, and whether the good outweighs the bad.
Unfortunately I don't really know where to start looking.

>
> Yes, strings are problematic to some degree, but it's still better than 
> increasing language complexity for a very edge case.
>
> Alternatively, a better way to embed other languages can be used, which would 
> be much more useful for things like Twig, Blade, PHPTal, SQL, etc: In 
> haskell, this is done via Template Haskell, which many like, and many loathe, 
> but is still useful for type-safe operations with a different language than 
> the "main" one: 
> https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates
>
> In addition to all the above, I just noticed that the entire reflection API 
> in the RFC requires major BC breaks in the reflection API... sigh.

Interesting. What exactly is going to break BC?

>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

--
PHP Internals - PHP Runtime 

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Nikita Popov]

On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux 
wrote:

> Hello internals,
>
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
>
> To review past discussions on this RFC and the feature in general, please
> refer to:
>
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and
> fact-finding
>
> Jordan
>

Voted No on this one. I did support the previous proposal on this topic,
but I don't like the changes that this iteration has introduced relative to
the previous proposal.

The part that I dislike most (and that I consider an exclusion criterion
regardless of any other merits of the proposal) is the introduction of a
new "operator +" style syntax. I found the motivation for this choice given
in the RFC rather weak -- it seems to be a very speculative
forward-compatibility argument, and I'm not sure it holds water even if we
accept the premise. There's nothing preventing us, from a technical
point-of-view, from allowing the use of some keyword only with magic
methods. On the other hand, the cost of this move is immediate: All tooling
will have to deal with a new, special kind of method declaration.

I'm also not a fan of the OperandPosition approach, though I could probably
live with it. The previous approach using static methods seemed more
natural to me, especially when it comes to operators that do not typically
commute (e.g. subtraction).

Regards,
Nikita

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Hennings]

One question that just occured to me:
Why allow the "public" keyword for visibility, if operators are public
automatically, and "private" and "protected" are not allowed?
Do we plan for private/protected operators in the future?
Shouldn't we eliminate meaningless choice?

On Mon, 3 Jan 2022 at 01:14, Jordan LeDoux  wrote:
>
> Hello internals,
>
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
>
> To review past discussions on this RFC and the feature in general, please
> refer to:
>
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
>
> Jordan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Christoph M. Becker]

On 03.01.2022 at 18:03, Horváth V. wrote:

> Thanks for the reply. It's very helpful.
>
> The glib issue is an upstream issue on Windows:
> https://gitlab.gnome.org/GNOME/glib/-/issues/692

Ah, sorry, that shouldn't be a problem (at least for Windows), since we
need *shared* libraries there anyway.

> ICU's Conan recipe doesn't support some platforms:
> https://github.com/conan-io/conan-center-index/blob/4011e625faf3c9de7b5a3c37cc736a6545ff9152/recipes/icu/all/conanfile.py#L76-L101

Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
might be okayish, though.  ICU ships a VS solution file
(source/allinone/allinone.sln) which works fine.  I don't know whether
using that would be okay for Conan.

Also note that we're using a patched libffi[1]; since that patch is not
complete, I didn't submit it upstream, but at least this basic
__vectorcall support is important for ext/ffi.

[1]


Regards,
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Rowan Tommins]

On 3 January 2022 16:07:53 GMT, Chase Peeler  wrote:
>My mistake, I thought it did get casted. Still, I think you add a lot of
>complexity because you'll need to keep track of whether or not a key was a
>string or not. There is no guarantee that all numeric keys were originally
>a string:
>[ "1" => "foo", 2 => "bar"]

I don't think anybody was proposing any such tracking, simply a shorthand for 
this:

array_map(strval(...), array_keys($array));

In other words, take the keys of any array, which might be a mixture of 
integers and strings, and convert them all to strings, regardless of how they 
were originally specified. The result being an array where the values can all 
be safely passed to a function expecting strings, with strict_types=1 in force.

Regards,

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Leathley]

On 03.01.22 17:12, Larry Garfield wrote:

Also, people keep talking about edge cases. In my experience, "are
these two objects equal" (for some object-specific definition of
equal) is very much *not* an edge case. I may have less use for
overloading % as I don't use advanced math that much, but I compare
things all the frickin' time and that would be incredibly useful day
to day.


Maybe some of the resistance against this RFC is the (understandable)
focus on mathematical (or mathematical-adjacent) operations, making it
seem that the "real" use-cases are narrow, whereas comparing objects
could make quite a bit of code more readable, like comparing addresses,
prices, availability or location/position. Having regular methods for
operators is possible, but when used a lot the readability does start to
suffer.

The difficulty in arguing for operator overloading might be that the use
cases are specific to a codebase and mainly become apparent once it is
available (currently you just work around it). I do think it is a
reasonable tool to make some code vastly more readable, and I don't see
"novices" using operators a lot - PHP has many simpler features to abuse
that can make code absolutely terrible.

The RFC is really well thought out and reasoned, by the way - great work
Jordan!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 17:12, Larry Garfield a écrit :

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much *not* an 
edge case.  I may have less use for overloading % as I don't use advanced math that much, 
but I compare things all the frickin' time and that would be incredibly useful day to day.


I forgot to answer to that, specifically. I'd much more prefer to have 
an explicit `equals(object $other): bool` (magic or not, really I do not 
care) single method for equality only, that'd be great. In that sense, I 
much preferred specific RFC about `__equalsTo()` or `__compareTo()` 
alone that a huge generic operator overload RFC. I think both could 
actually be separated, it wouldn't be that weird.


Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Horváth V .]

Thanks for the reply. It's very helpful.

The glib issue is an upstream issue on Windows:
https://gitlab.gnome.org/GNOME/glib/-/issues/692

ICU's Conan recipe doesn't support some platforms:
https://github.com/conan-io/conan-center-index/blob/4011e625faf3c9de7b5a3c37cc736a6545ff9152/recipes/icu/all/conanfile.py#L76-L101

Regards,
Horváth V.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 17:12, Larry Garfield a écrit :

On Mon, Jan 3, 2022, at 9:52 AM, Pierre wrote:


I personally tend to agree with everything that Marco said. Especially
regarding the fact that it's adding huge complexity to the language
itself for mostly edge cases.

I'd argue there's many much more valuable features that could be added
to PHP before operator overload, such as generics, rationalized
collection API and scalar objects with methods for example (which all
could be magnificent tools for improving the operator overload RFC).

Those are all independent of operator overloading.  There's zero reason one 
needs to come before/after any other.  Everyone wants generics, but they're 
really hard or Nikita would have implemented them already.  This is a 
non-argument.

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much *not* an 
edge case.  I may have less use for overloading % as I don't use advanced math that much, 
but I compare things all the frickin' time and that would be incredibly useful day to day.


I think you read it too quickly. Anyway it was just examples, my point 
is not specifically about generics, but about the fact that operator 
overloading has been hugely controversial, and independently of the fact 
that I think this is a very well documented RFC, I still don't like it 
and express my opinion, I probably would not use those, but I eventually 
will be step debugging into some, and god, I don't wish I'll have to, 
really, I hate magic and non verbose code. Nevertheless, I have to 
admit, if I had the right to vote, I would abstain because it still a 
feature a lot of people want.


Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Christoph M. Becker]

On 03.01.2022 at 17:29, Horváth V. wrote:

> I have created an issue to track dependencies for PHP:
> https://github.com/conan-io/conan-center-index/issues/8618
>
> Please take a look, verify that all of those are needed and if anyone
> has answers for the few questions I have as sublist items, then that
> would help greatly as well.

glib: yes, that should be shared libraries; at least parts of that
package are used by some PECL extensions

ICU: "Some platforms aren't supported." – which platforms?

libargon2: should probably be available in addition to the libsodium
implementation; might be acceptable if not

libintl: is indeed the supporting library for gettext

libsodium: support for VS < 2019 is unlikely to be needed

And yes, all these are needed (maybe libargon2 not necessarily) for
php-src.  There are many more for PECL extensions.

Regards,
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Horváth V .]

I have created an issue to track dependencies for PHP:
https://github.com/conan-io/conan-center-index/issues/8618

Please take a look, verify that all of those are needed and if anyone
has answers for the few questions I have as sublist items, then that
would help greatly as well.

Regards,
Horváth V.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Larry Garfield]

On Mon, Jan 3, 2022, at 9:52 AM, Pierre wrote:

> I personally tend to agree with everything that Marco said. Especially 
> regarding the fact that it's adding huge complexity to the language 
> itself for mostly edge cases.
>
> I'd argue there's many much more valuable features that could be added 
> to PHP before operator overload, such as generics, rationalized 
> collection API and scalar objects with methods for example (which all 
> could be magnificent tools for improving the operator overload RFC).

Those are all independent of operator overloading.  There's zero reason one 
needs to come before/after any other.  Everyone wants generics, but they're 
really hard or Nikita would have implemented them already.  This is a 
non-argument.

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much 
*not* an edge case.  I may have less use for overloading % as I don't use 
advanced math that much, but I compare things all the frickin' time and that 
would be incredibly useful day to day.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Chase Peeler]

On Mon, Jan 3, 2022 at 10:48 AM Rowan Tommins 
wrote:

> On 3 January 2022 15:41:48 GMT, Chase Peeler 
> wrote:
> >But "001" casted to 1 will then get casted back to "1" not "001".
>
> "001" would not be cast to an integer in this context:
> https://3v4l.org/gGFHJ
>
>
My mistake, I thought it did get casted. Still, I think you add a lot of
complexity because you'll need to keep track of whether or not a key was a
string or not. There is no guarantee that all numeric keys were originally
a string:
[ "1" => "foo", 2 => "bar"]

And, for the record, I am not in favor of the original proposal either. I
think it's way too big of a BC break like others have said.


> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 16:00, Marco Pivetta a écrit :
I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that 
unreadable, and there is no need to abbreviate it to "diff" either.
Whether it needs to be static methods or instance methods depends on 
the wished API design.


What this RFC aims at is a mathematical language, inside another 
general purpose language: for complex expressions, I'd probably run it 
in a subsystem dedicated to this instead.


See for example:

 * https://en.wikipedia.org/wiki/Expression_(mathematics) (I'm 
literally just picking a complex example - don't even know how to read 
that properly)
 * and its textual representation in 
https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)=edit=1 



```php
$expression = <<<'MATH'
f(a)+\sum_{k=1}^n\left.\frac{1}{k!}\frac{d^k}{dt^k}\right|_{t=0}f(u(t)) 
+ \int_0^1 \frac{(1-t)^n }{n!} \frac{d^{n+1}}{dt^{n+1}} f(u(t))\, dt.

MATH;

$result = $userlandExpressionEngine->evaluate(
    $expression,
    [
 // ... bind parameters here 
    ]
);
```

Heck, I can probably ask the `$userlandExpressionEngine` to render 
that monstrosity for me (see attachment).


Note that we do this stuff constantly for SQL, yet we haven't designed 
a system for embedding SQL into the language, and still, SQL is used 
many magnitudes more than all what was discussed in this RFC.


Yes, strings are problematic to some degree, but it's still better 
than increasing language complexity for a very edge case.


Alternatively, a better way to embed other languages can be used, 
which would be much more useful for things like Twig, Blade, PHPTal, 
SQL, etc: In haskell, this is done via Template Haskell, which many 
like, and many loathe, but is still useful for type-safe operations 
with a different language than the "main" one: 
https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates


In addition to all the above, I just noticed that the entire 
reflection API in the RFC requires major BC breaks in the reflection 
API... sigh.


Marco Pivetta


Hello,

I personally tend to agree with everything that Marco said. Especially 
regarding the fact that it's adding huge complexity to the language 
itself for mostly edge cases.


I'd argue there's many much more valuable features that could be added 
to PHP before operator overload, such as generics, rationalized 
collection API and scalar objects with methods for example (which all 
could be magnificent tools for improving the operator overload RFC).


I'm not against explicit method call, it's both readable and navigable, 
whereas operator overload tend to magically hide what the code really does.


Best regards,

--

Pierre

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Rowan Tommins]

On 3 January 2022 15:41:48 GMT, Chase Peeler  wrote:
>But "001" casted to 1 will then get casted back to "1" not "001".

"001" would not be cast to an integer in this context: https://3v4l.org/gGFHJ

Regards,

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Chase Peeler]

On Sun, Jan 2, 2022 at 7:05 AM Rowan Tommins 
wrote:

> On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov  wrote:
> >
> >I just gave an example of what at the moment can cause an exception in
> any application that is based on the PSR. It is enough to send the header
> "0: Farewell to the server". In some cases (for example, as is the case
> with RoadRunner) - this can cause a physical stop and restart of the server.
>
> Any library where a crafted HTTP request can cause a server shutdown has a
> bug which needs addressing right now - possibly more than one, actually, as
> it implies error handling is leaking across request boundaries. A change to
> the language applied in the next major version would fix this some time
> around 2025, once people start adopting it. A workaround in the library
> itself can be applied within weeks.
>
> I already gave a simple solution that such libraries can apply right now,
> with very little chance of negative impact: sanitise headers more
> aggressively than the HTTP standard requires, as Apache httpd does, in this
> case discarding any header containing only digits. This is likely to be
> about three lines of code inside a loop preprocessing raw headers:
>
> if ( ctype_digit($rawHeaderName) ) {
>  trigger_error("Numeric HTTP header '$rawHeaderName' has been
> discarded.", E_USER_WARNING);
>  continue;
> }
>
> If I was the maintainer of such a library, I might consider even stricter
> validation, considering what seems like an accidentally broad definition in
> the HTTP spec, and the possibility of an application receiving even more
> exotic characters if processing raw TCP traffic.
>
>
> The idea of an array_keys variant or option that forces everything back to
> string seems like it might be useful (and easy to polyfill for old
> versions). Changing such a fundamental language behaviour in the hope that
> it will fix more code than it breaks is just not worth it.
>
>
But "001" casted to 1 will then get casted back to "1" not "001".



> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Marco Pivetta]

Hey Andreas,

On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings  wrote:

> I imagine that operator overloads can improve DX for these use cases,
> but at a cost for the overall language.
>
> How would you (Marco) see the future of arithmetic libraries for time,
> money etc without overloaded operators?
> How would these calculations look like e.g. with infix functions?
> Do you think this can eliminate the desire for operator overloads?
>

> E.g. something like this?
>
> $ts0 = new Timestamp($seconds0);
> $ts1 = new Timestamp($seconds1);
> /** @var Duration $duration */
> $duration = $ts1 - $ts0;  // Operator overload notation.
> $duration = Duration::betweenTimestamps($ts0, $ts1);  // Static method
> notation.
> $duration = $ts1->diff($ts0);  // Object method notation.
> $duration = $ts0  $ts1  // Infix notation
> based on static method.
> $duration = $ts1  $ts0  // Infix notation based on object method.
>

I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that
unreadable, and there is no need to abbreviate it to "diff" either.
Whether it needs to be static methods or instance methods depends on the
wished API design.

What this RFC aims at is a mathematical language, inside another general
purpose language: for complex expressions, I'd probably run it in a
subsystem dedicated to this instead.

See for example:

 * https://en.wikipedia.org/wiki/Expression_(mathematics) (I'm literally
just picking a complex example - don't even know how to read that properly)
 * and its textual representation in
https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)=edit=1

```php
$expression = <<<'MATH'
f(a)+\sum_{k=1}^n\left.\frac{1}{k!}\frac{d^k}{dt^k}\right|_{t=0}f(u(t)) +
\int_0^1 \frac{(1-t)^n }{n!} \frac{d^{n+1}}{dt^{n+1}} f(u(t))\, dt.
MATH;

$result = $userlandExpressionEngine->evaluate(
$expression,
[
 // ... bind parameters here 
]
);
```

Heck, I can probably ask the `$userlandExpressionEngine` to render that
monstrosity for me (see attachment).

Note that we do this stuff constantly for SQL, yet we haven't designed a
system for embedding SQL into the language, and still, SQL is used many
magnitudes more than all what was discussed in this RFC.

Yes, strings are problematic to some degree, but it's still better than
increasing language complexity for a very edge case.

Alternatively, a better way to embed other languages can be used, which
would be much more useful for things like Twig, Blade, PHPTal, SQL, etc: In
haskell, this is done via Template Haskell, which many like, and many
loathe, but is still useful for type-safe operations with a different
language than the "main" one:
https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates

In addition to all the above, I just noticed that the entire reflection API
in the RFC requires major BC breaks in the reflection API... sigh.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Andreas Hennings]

On Mon, 3 Jan 2022 at 02:07, Marco Pivetta  wrote:
>
> Hey Jordan,
>
> I've voted "no" on this one: infix functions may have been interesting, but
> adding a whole new type system around operators is really not worth it,
> given:
>
>  * Added AST nodes
>  * Added method definitions for niche use-cases
>  * Complexity in support for static analysis tools
>
> I personally don't see a reason to introduce all this for examples like the
> one with GMP, which was more readable before adopting userland custom
> operators.
>
> In addition to all that, we didn't even achieve custom operators anyway:
> it's just the built-in ones (this is why I mentioned infix functions), and
> the precedence, number and type of operands are fixed too (yes, it is a
> sensible starting choice, but very little "custom" about it).
>
> Overall, your RFC is exactly what I would expect a custom operator RFC for
> PHP to look like: I just don't think the feature is needed at all, as it
> only makes the language much more complex, for rare cases that I hope I
> will never ever have to debug in future.

Perhaps we need more discussion about use cases to justify this RFC?

I think the main use cases mentioned so far were for arithmetic
operations between value objects that represent money, time, or other
measurable values, or mathematical higher-order values (vectors etc).

I imagine that operator overloads can improve DX for these use cases,
but at a cost for the overall language.

How would you (Marco) see the future of arithmetic libraries for time,
money etc without overloaded operators?
How would these calculations look like e.g. with infix functions?
Do you think this can eliminate the desire for operator overloads?

E.g. something like this?

$ts0 = new Timestamp($seconds0);
$ts1 = new Timestamp($seconds1);
/** @var Duration $duration */
$duration = $ts1 - $ts0;  // Operator overload notation.
$duration = Duration::betweenTimestamps($ts0, $ts1);  // Static method notation.
$duration = $ts1->diff($ts0);  // Object method notation.
$duration = $ts0  $ts1  // Infix notation
based on static method.
$duration = $ts1  $ts0  // Infix notation based on object method.

I generally like names I can click on, if they don't get too long..
I like if the choice of implementation is knowable by just looking at the code.
(with a small range of runtime polymorphism)
I like if some functionality is implemented outside of object methods,
keeping interfaces and inheritance chains simple.

But for code with lots of calculations, a simple "-" feels simpler and
more explanatory than something like "diff" or "timediff", where I
have to reference and remember a specific method/function name.

-- Andreas


> Greets,
>
> Marco

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Larry Garfield]

On Sun, Jan 2, 2022, at 6:13 PM, Jordan LeDoux wrote:
> Hello internals,
>
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
>
> To review past discussions on this RFC and the feature in general, please
> refer to:
>
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
>
> Jordan

I have voted Yes on this RFC as well.

PHP right now is littered with inconsistencies between its various types.  
Redesigning the whole thing is obviously impossible, but allowing objects to 
hook into behaving like other values piecemeal (as this RFC does) is probably 
the best option available.  Not every object will need every operator, and 
that's fine, but in places where they are useful, they will be *really* useful.

I just ran into a place 2 weeks ago where the <=> or == overrides would have 
saved me a ton of time and effort, and allowed objects to work with more 
existing utilities.  (In this case, in_array() with value objects, which right 
now is impossible without a ton more pointless work).  Just those alone justify 
the RFC for me.

I also believe this RFC handles more edge cases to nudge people toward good 
usage than any other proposal could.  I really don't see how it could do 
better, without relying on other, even more controversial unimplemented 
features that may never exist (method pattern matching).

I do think this is the best we'll be able to do on this front, it solves a real 
and present problem I do see in my own code, and it has clear extension points 
for the future (e.g., supporting arbitrary operator symbols if we ever decide 
to).  That's all we can ask for from an RFC, so this has my vote.

(I also find it odd to argue that it is bad because it will lead to confusing 
code, but at the same time argue it's bad because it doesn't allow arbitrary 
operator definitions.  Those seem mutually contradictory positions.)

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Bob Weinand]

> Am 03.01.2022 um 01:13 schrieb Jordan LeDoux :
> 
> Hello internals,
> 
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
> 
> To review past discussions on this RFC and the feature in general, please
> refer to:
> 
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
> 
> Jordan

Hey Jordan,

thanks for bringing it up to a vote.

I've voted for an inclusion, for the primary reason, that in general, it does, 
in fact, not get abused too much.

It seems to me, that many of the no-voters fear codebases riddled with random 
operator overloads where they make no sense.
I don't share that sentiment. Yes, there will always be some outliers, but it 
shouldn't hinder the general improvement it brings to readability and 
expressiveness. (I strongly disagree that gmp overloads are a net negative.)

For my part, I have had a positive experience with operator overloads in C#. 
They tend to not be overused, make Vector operations graspable (once you have a 
mental model of what vector operations feel and look like…).
In the past I've really hated writing, and especially reading math heavy code 
on something different than the standard euclidean space in PHP. (Vectors, 
complex numbers, integer spaces with a finite size…)
I truly hope this RFC passes, so that these abominations of nested math calls 
may disappear.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php