Hi internals,
I have closed the voting. With 38 in favor and 28 against the RFC is DECLINED
(didn’t reach the needed 2/3 majority for a new feature).
Thanks to everyone who has participated.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thursday, March 26, 2020 6:19 PM Guilliam Xavier
wrote:
>> If the concat operator is not overloaded, the behavior is like now, and the
>> objects are converted implicitly to strings (so $a . $b actually means
>> (string) $a . (string) $b).
>> Furthermore an notice is triggered, hinting the
On Thursday, March 26, 2020 3:50 AM Jakob Givoni wrote:
> On Wed, Mar 25, 2020 at 6:28 AM Christoph M. Becker wrote:
>
>> It seems to me that the RFC is not sufficiently specific enough
>> regarding the concatenation of instances of classes which implement
>> __toString().
>
> Exactly what I
Hi internals,
I have opened voting on
https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
to overload operators in their own classes.
Voting closes on 2020-04-06.
Regards,
Jan Böhmer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote:
> Hi internals,
>
> based on the discussions here (https://externals.io/message/108300) and
here
> (https://github.com/php/php-src/pull/5156), I have created a proper RFC
for
> userspace operator overloading:
>
> ) I know you're not alone in that feeling. If it turns out this is the
majority view, I think it answers a couple of open questions:
>
> Overload methods should definitely be named after operations, not symbols,
to remind people they are implementing addition, not giving new meaning to +
>
>
On 16/02/2020 01:17, marand...@php.net wrote:
> N :( Notices are the enemy of all that is great and good.
>
> If operator overloading is going to become a first-class feature then it
> should be treated as such, and attempting overloading operators on
> objects that don't have the relevant
Hi internals,
based on the discussions here (https://externals.io/message/108300) and here
(https://github.com/php/php-src/pull/5156), I have created a proper RFC for
userspace operator overloading:
https://wiki.php.net/rfc/userspace_operator_overloading
The main differences to my original
On Sat, Feb 1, 2020 10:22 AM wrote:
> Looks much better! If you submit a pull request, I can leave some more
> detailed comments.
Okay, I will submit a pull request with my changes.
> If you would like to start an RFC on this topic, please sign up for a wiki
> account
> I cannot speak to the implementation details. From a design perspective,
I am tentatively positive on operator overloading, with separate method for
each operator, BUT, the big question for me is the rules around type
compatibility.
>
> Can you only compare 2 of the same type? What about
> Unfortunately, this implementation goes in the wrong direction: PHP already
> has full internal support for operator overloading through the do_operation
> object handler. Operator overloading should be exposed to userland through
> that handler as well.
I have made another implementation
> I would recommend not handling overloading of comparisons in the same
> proposal. Comparison is more widely useful than other overloading and has a
> more complex design space (especially when it comes to accommodating objects
> that can only be compared for equality/inequality for example).
Hello everybody,
the last days I have experimented a bit with operator overloading in
userspace classes (redefing the meaning of arithmetic operations like +, -,
*, etc. for your own classes).
This could be useful for different libraries which implements custom
arithmetic objects (like money
13 matches
Mail list logo
