Re: [PHP-DEV] The future of objects and operators

2022-06-14 Thread Robert Landers
On Fri, May 13, 2022 at 4:49 PM Jordan LeDoux wrote: > > On Fri, May 13, 2022 at 7:05 AM Rowan Tommins > wrote: > > > > > I like Larry's "4 levels", but I've been thinking that there's some > > existing functionality in PHP which takes a different direction: rather > > than overloading

Re: [PHP-DEV] The future of objects and operators

2022-05-13 Thread Jordan LeDoux
On Fri, May 13, 2022 at 7:05 AM Rowan Tommins wrote: > > I like Larry's "4 levels", but I've been thinking that there's some > existing functionality in PHP which takes a different direction: rather > than overloading *operators*, the language lets you overload *behaviour*. > We have magic

Re: [PHP-DEV] The future of objects and operators

2022-05-13 Thread Larry Garfield
On Fri, May 13, 2022, at 9:05 AM, Rowan Tommins wrote: > On 6 May 2022 23:16:37 BST, Jordan LeDoux wrote: >>I'm not sure at this point how voters think objects and operators should >>work together into the future. I'd like to see if anyone is willing to have >>high-level discussion about the

Re: [PHP-DEV] The future of objects and operators

2022-05-13 Thread Rowan Tommins
On 6 May 2022 23:16:37 BST, Jordan LeDoux wrote: >I'm not sure at this point how voters think objects and operators should >work together into the future. I'd like to see if anyone is willing to have >high-level discussion about the ideas, instead of picking at the >implementation or details of a

Re: [PHP-DEV] The future of objects and operators

2022-05-12 Thread Jordan LeDoux
On Mon, May 9, 2022 at 2:25 PM Larry Garfield wrote: > > Also, not proposing level 1 on the grounds that it would reduce the > argument for level 2/3 in the future would effectively be holding level 1 > functionality "hostage" for the more advanced versions, which... would > probably not work

Re: [PHP-DEV] The future of objects and operators

2022-05-09 Thread Larry Garfield
On Sat, May 7, 2022, at 3:59 PM, Jordan LeDoux wrote: > Of the people who did vote no and also provided me feedback, there were > *mainly* three reasons given (some in public such as on this list, and some > in private in more direct conversation): > > 1. Math is not a valid use case. > 2.

Re: [PHP-DEV] The future of objects and operators

2022-05-08 Thread Andreas Leathley
On 07.05.22 22:59, Jordan LeDoux wrote: I like the way you organized the different levels of support within the feature, it's a good organizational structure for thinking about the feature-set. Given the feedback though, I found myself a little concerned that if I created a Level 1 proposal,

Re: [PHP-DEV] The future of objects and operators

2022-05-07 Thread MKS Archive
> On May 6, 2022, at 6:16 PM, Jordan LeDoux wrote: > > Hello all, > > I took a while away after my operator overload RFC was declined. I've been > mulling for the last few months how to move forward while respecting the > concerns and feedback of those who abstained and those who voted

Re: [PHP-DEV] The future of objects and operators

2022-05-07 Thread Jordan LeDoux
On Sat, May 7, 2022 at 11:40 AM Larry Garfield wrote: > > I would group object operators into 4 categories/levels. > > 1. Object-universal operators. This would be support for operators that > make sense in all domains. Mainly this is the comparison operators but > there may be others. > 2.

Re: [PHP-DEV] The future of objects and operators

2022-05-07 Thread Larry Garfield
On Fri, May 6, 2022, at 5:16 PM, Jordan LeDoux wrote: > Hello all, > > I took a while away after my operator overload RFC was declined. I've been > mulling for the last few months how to move forward while respecting the > concerns and feedback of those who abstained and those who voted against. >

[PHP-DEV] The future of objects and operators

2022-05-06 Thread Jordan LeDoux
Hello all, I took a while away after my operator overload RFC was declined. I've been mulling for the last few months how to move forward while respecting the concerns and feedback of those who abstained and those who voted against. But I feel like a separate discussion needs to happen first