On Wed, May 10, 2023, at 11:35 AM, Robert Landers wrote:
>> Regarding $field vs. $this->propName, there's a few reasons we went that
>> route.
>>
>> 1. It's shorter and less typing for what will be a common pattern.
>> 2. That makes it consistent between hook implementations. In working on
>>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
>
> 1. It's shorter and less typing for what will be a common pattern.
> 2. That makes it consistent between hook implementations. In working on
> examples, I found many cases where I was adding basically the
On Mon, 1 May 2023 at 18:09, Benjamin Außenhofer
wrote:
> On Fri, Apr 28, 2023 at 12:01 PM Jakub Zelenka wrote:
>
> > Hi,
> >
> > The vote is now open for the RFC about introduction of the PHP Technical
> > Committee:
> >
> > https://wiki.php.net/rfc/php_technical_committee
>
>
> I found this
On Mon, 1 May 2023 at 19:29, Jakub Zelenka wrote:
> Hi,
>
> Thanks for the feedback.
>
> On Mon, May 1, 2023 at 4:09 PM Benjamin Außenhofer
> wrote:
>
> However the main problem with the RFC process is that for purely technical
> changes it could result in a set of rules that will limit core
Hi Dan (and Larry and Tim who responded to the same topic),
Would leaving the current versions in place and working actually cause
> any maintenance issues?
Yes, unfortunately they cause some maintenance issues: since they don't
have a single
signature, gen_stub.php generates the wrong
Hi Derick and Tim,
Derick, I incorporated most of your suggestions into the RFC with the sole
exception of the argument
names ($start/$finish,$begi/$end): it would feel odd if these parameters
and their related properties
were called differently:
Hi Rowan,
> As an aside, I don't think "other deprecations are already more difficult"
> is a good argument - it's like saying "yes, I punched him, but not as hard
> as someone else already had". I think the change can be defended from other
> angles, but wanted to call that out.
>
I admit that
