Actually, on second glance, it seems that they make a call to zend_compare.
So currently they would all work with an implementation of <=> but not ==.
So I'd mostly just need to update the fast_equal_check_function.
Jordan
Apologies. I think I saw this, but then was distracted by other matters and
lost track of it.
This will not work because it will first try A->{'/'}(B) that throws a
>> TypeError? So it means what I was able to do for floats, cannot be done for
>> my new classes afterwards? This is inconsistent I
Hi Jordan,
Many thanks for all your replies. But did you miss Côme's mail (maybe
because you weren't direct recipient)? Anyway, here it is again:
On Tue, Jan 4, 2022 at 10:02 AM Côme Chilliet wrote:
> Hello,
>
> From the RFC:
>
> > If the left operand produces a TypeError due to the parameter
On Wed, Jan 5, 2022 at 3:24 PM Andreas Hennings wrote:
> On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux
> wrote:
> >
> >
> >
> > On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings
> wrote:
> >>
> >> Hello Jordan,
> >> do you have any thoughts about these symmetric/left/right modifiers,
> >> to get
On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux wrote:
>
>
>
> On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings wrote:
>>
>> Hello Jordan,
>> do you have any thoughts about these symmetric/left/right modifiers,
>> to get rid of the $operandPos parameter?
>>
>> To me, the parameter could be the kind of
On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings wrote:
> Hello Jordan,
> do you have any thoughts about these symmetric/left/right modifiers,
> to get rid of the $operandPos parameter?
>
> To me, the parameter could be the kind of thing where in hindsight we
> ask "why?".
>
> Also, can we drop
Hello Jordan,
do you have any thoughts about these symmetric/left/right modifiers,
to get rid of the $operandPos parameter?
To me, the parameter could be the kind of thing where in hindsight we
ask "why?".
Also, can we drop the "public" modifier, if we do a new version of the RFC?
Cheers
On 05.01.22 10:42, Jordan LeDoux wrote:
I suppose the alternative would be to withdraw the RFC
now that a wider variety of voters are providing feedback than the other
three threads.
I would let the vote go on, as there are still many voters who have not
voted on this yet, giving the proposal
Hey Jordan.
On 05.01.22 10:42, Jordan LeDoux wrote:
On Tue, Jan 4, 2022 at 10:50 PM Pierre Joye wrote:
I hesitated too, however I think we can't escape this feature. Like it
was for the annotation, we need to find a compromise.
Your points are valid so I wonder if the RFC could be modified
On Tue, Jan 4, 2022 at 10:50 PM Pierre Joye wrote:
>
> I hesitated too, however I think we can't escape this feature. Like it
> was for the annotation, we need to find a compromise.
>
> Your points are valid so I wonder if the RFC could be modified and get
> to the point we could reach that
On Wed, Jan 5, 2022 at 12:26 AM Aleksander Machniak wrote:
>
> - what is the performance impact?
>
Each operator evaluation is very slightly better than the equivalent
function call, since the VM call chain is very slightly simpler, but for
most purposes you can think of the performance as
On 03.01.2022 01:13, Jordan LeDoux wrote:
https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
close on 2022-01-17.
- what is the performance impact?
- why "[public] operator" and not "operator function"?
- what about precedence, i.e. what happens with $a + $b * $c?
Hi Nikita,
On Tue, Jan 4, 2022 at 12:38 AM 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
On Wed, Jan 5, 2022 at 3:19 AM Jordan LeDoux
wrote:
>
> On Tue, Jan 4, 2022 at 1:27 AM Marco Pivetta wrote:
>
> Can I expect this for other math related RFCs, or is this dogmatic about
> operator overload specifically? I have no clue, and at the very least, I
> would like to learn that.
>
It's
On Tue, Jan 4, 2022 at 1:27 AM Marco Pivetta wrote:
>
> I know you're picking on details here, but believe me, I'm serious when
> I'm saying "use matlab".
>
> In fact, I did work on financial products where (from Java PHP and Python)
> we used the MATLAB Compiler to create binaries and dynamic
Hey Jordan,
On Tue, Jan 4, 2022 at 3:23 AM Jordan LeDoux
wrote:
> > 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:
Hello,
From the RFC:
> If the left operand produces a TypeError due to the parameter types listed in
> the implementation, the operation is not retried with the right operand and
> the error is instead returned immediately. This is to help developers
> encounter errors in their program logic
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
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
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,
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
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
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
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
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:
>
> -
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
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
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
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
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
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
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
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
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:
>
> -
> 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:
>
> -
On Sun, Jan 2, 2022 at 5:07 PM 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
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
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
-
38 matches
Mail list logo
