On Thu, Apr 9, 2020, at 10:05 AM, Rowan Tommins wrote:
> On Thu, 9 Apr 2020 at 13:18 (and subsequent correction), Dan Ackroyd <
> dan...@basereality.com> wrote:
>
> > > $a = new A;
> > > $b = new B;
> > > var_dump($b + $a); # calls B::__add($b, $a); OK
> > > var_dump($a + $b); # calls
On Thu, 9 Apr 2020 at 13:18 (and subsequent correction), Dan Ackroyd <
dan...@basereality.com> wrote:
> > $a = new A;
> > $b = new B;
> > var_dump($b + $a); # calls B::__add($b, $a); OK
> > var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError
>
>
> ... that code does have a
On 09.04.2020 at 14:41, Dan Ackroyd wrote:
> On Thu, 9 Apr 2020 at 13:18, Dan Ackroyd wrote:
>
>> It appears to be the same error case as:
>>
>
> And that code had a mistake. Should have been:
>
> ```
> class A {
> public function add(A $rhs) {...}
> }
>
> class B {
> public function
On Thu, 9 Apr 2020 at 13:18, Dan Ackroyd wrote:
> It appears to be the same error case as:
>
And that code had a mistake. Should have been:
```
class A {
public function add(A $rhs) {...}
}
class B {
public function add(A|B $rhs) {...}
}
$a = new A;
$b = new B;
$b->add($a); // Ok
On Mon, 6 Apr 2020 at 20:36, wrote:
>
> 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.
>
Hi Jan,
Thanks for running the RFC. Although it
On Mon, Apr 6, 2020 at 2:36 PM wrote:
> 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).
>
> Please don't be discouraged. I did vote against, but I was on the fence
(My vote was 'Yes' for a period). Review
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 Sat, Mar 28, 2020 at 10:19 PM Andrea Faulds wrote:
> Hi everyone,
>
> Johannes Schlüter wrote:
> >
> > If we use two methods as well it is a saner design. I won't like it, but
> lot better than the current one.
>
> Just want to +1 this. Two methods, neither of which are static, seems
> like a
Stanislav wrote:
I think "as long as it is not overused" are the key words there. We
have a very limited number of internal classes with operator
overloading
I think the whole point of leaving it to extensions was ensuring it's
not overused. And now I see people arguing "well, if it's
Hi!
> I think “as long as it is not overused” are the key words there. We have
> a very limited number of internal classes with operator overloading
I think the whole point of leaving it to extensions was ensuring it's
not overused. And now I see people arguing "well, if it's available to
On 28.03.2020 at 22:21, Andrea Faulds wrote:
> Christoph M. Becker wrote:
>> (frankly, I would not have not supported __concat() at all). Also,
>> overloaded operators should be programmed defensively, i.e. they should
>> not accept arbitrary arguments (how could that even work?), but only
>>
Hi,
Christoph M. Becker wrote:
(frankly, I would not have not supported __concat() at all). Also,
overloaded operators should be programmed defensively, i.e. they should
not accept arbitrary arguments (how could that even work?), but only
those they can handle. If implementations adhere to
Hi everyone,
Johannes Schlüter wrote:
If we use two methods as well it is a saner design. I won't like it, but lot
better than the current one.
Just want to +1 this. Two methods, neither of which are static, seems
like a cleaner approach to me. I maybe like this better than my
suggested
On March 28, 2020 5:44:28 PM GMT+01:00, Nikita Popov
wrote:
>On Sat, Mar 28, 2020 at 5:28 PM Johannes Schlüter
>
>wrote:
>
>> On Sat, 2020-03-28 at 17:05 +0100, Christoph M. Becker wrote:
>> > On 28.03.2020 at 15:57, Johannes Schlüter wrote:
>> >
>> > > On March 28, 2020 1:25:11 PM GMT+01:00,
On Sat, Mar 28, 2020 at 5:28 PM Johannes Schlüter
wrote:
> On Sat, 2020-03-28 at 17:05 +0100, Christoph M. Becker wrote:
> > On 28.03.2020 at 15:57, Johannes Schlüter wrote:
> >
> > > On March 28, 2020 1:25:11 PM GMT+01:00, "Christoph M. Becker" <
> > > cmbecke...@gmx.de> wrote:
> > >
> > > >
On Sat, 2020-03-28 at 17:05 +0100, Christoph M. Becker wrote:
> On 28.03.2020 at 15:57, Johannes Schlüter wrote:
>
> > On March 28, 2020 1:25:11 PM GMT+01:00, "Christoph M. Becker" <
> > cmbecke...@gmx.de> wrote:
> >
> > > This "try left/right" approach is how operator overloading works
> > >
On 28.03.2020 at 15:57, Johannes Schlüter wrote:
> On March 28, 2020 1:25:11 PM GMT+01:00, "Christoph M. Becker"
> wrote:
>
>> This "try left/right" approach is how operator overloading works for
>> internal classes[1], and apparently, it works quite well, as long as it
>> is not overused.
>
>
On 28.03.2020 at 14:29, Andrea Faulds wrote:
> Christoph M. Becker wrote:
>
>> This "try left/right" approach is how operator overloading works for
>> internal classes[1], and apparently, it works quite well, as long as it
>> is not overused.
>
> I think “as long as it is not overused” are the
On March 28, 2020 1:25:11 PM GMT+01:00, "Christoph M. Becker"
wrote:
>On 28.03.2020 at 10:22, Arnold Daniels wrote:
>
>> This issues become even more apparent when sequencing operations like
>`$a +
>> $b + $c - $d`. Trying left, then trying right, will make it very
>difficult
>> to determine
Hi Johannes,
Johannes Schlüter wrote:
I believe the pre-requisit is having some form of function overloading,
where operator functions for specific argument types can be defined. In
https://news-web.php.net/php.internals/108425 Andrea created an idea,
which is probably "ugly" but has less usage
Hi,
Christoph M. Becker wrote:
On 28.03.2020 at 10:22, Arnold Daniels wrote:
This issues become even more apparent when sequencing operations like `$a +
$b + $c - $d`. Trying left, then trying right, will make it very difficult
to determine the outcome of such a statement.
The arguments
Am 27.03.2020 um 21:10 schrieb Johannes Schlüter:
However I don't like this design.
[...]
Changed my vote back to "no" based on Johannes' arguments.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Michał Brzuchalski wrote:
The first thing is for operator methods when the operation is not supported
I would see simply `return null;` as the right solution
instead of constant, which name no one will remember.
If we are to allow arbitrary use of operator overloading (rather than
On 28.03.2020 at 10:22, Arnold Daniels wrote:
> This issues become even more apparent when sequencing operations like `$a +
> $b + $c - $d`. Trying left, then trying right, will make it very difficult
> to determine the outcome of such a statement.
>
> The arguments against type hinting for
>
>
> On Mon, 2020-03-23 at 18:58 +0100, jan.h.boeh...@gmx.de wrote:
> > 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.
> >
>
> I consider operator overlaoding in general
On Mon, 2020-03-23 at 18:58 +0100, jan.h.boeh...@gmx.de wrote:
> 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.
>
I consider operator overlaoding in general a good feature
I accept that it adds an extra level of understanding to the language – if
you see
function addAmounts($a, $b) { return $a + $b; }
you no longer definitely know the answer will be numeric.
However, I imagine that the sorts of people who will use this are _also_
the sorts of people who would add
pon., 23 mar 2020 o 18:58 napisał(a):
> 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.
>
I got two comments, a little late but always better than even later.
The first thing
On Thu, 26 Mar 2020, Derick Rethans wrote:
> On Mon, 23 Mar 2020, jan.h.boeh...@gmx.de wrote:
>
> > I have opened voting on
> > https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> > to overload operators in their own classes.
>
> I've always been a strong proponent of
On Mon, 23 Mar 2020, jan.h.boeh...@gmx.de wrote:
> 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.
I've always been a strong proponent of operator overloading, but as PHP
Am 24.03.2020 um 11:06 schrieb Sebastian Bergmann:
I voted "no" for the same reason.
I changed my vote to "yes" because of Nikita's arguments.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, internals!
I want to mention, that all existing internal API of Zend could be
accessible via FFI as of PHP7.4. This gives opportunity to implement
userspace operator overloading as a simple PHP package.
I know, that FFI requires some polishing, but it could become a tool to
create
> 1. This is exposing functionality that already exists for internal classes
>
2. Because this just exposes existing functionality, the amount of
> technical complexity this introduces is very small
>
> 3. As mentioned, this functionality already exists internally and is used
> by GMP, where it
On Mon, Mar 23, 2020 at 6:58 PM wrote:
> 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
>
Thank you.
I voted yes
On Mon, Mar 23, 2020 at 6:58 PM wrote:
> 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
>
To offer a counter-point,
Am 24.03.2020 um 11:03 schrieb Marco Pivetta:
Just posting here why I voted "no": it is not your implementation proposal,
but rather the concept per-se that IMO shouldn't land in the language.
I voted "no" for the same reason.
--
PHP Internals - PHP Runtime Development Mailing List
To
Hey Jan,
Just posting here why I voted "no": it is not your implementation proposal,
but rather the concept per-se that IMO shouldn't land in the language.
Operator overloading makes call-site code reading extremely hard, and it
makes the language much more complex for very little benefit.
37 matches
Mail list logo
