Re: [RFC]I'd like to see the RFCs that deprecate the FFI non-static approach start voting

From: Date: Sun, 07 Jul 2024 07:10:30 +0000
Subject: Re: [RFC]I'd like to see the RFCs that deprecate the FFI non-static approach start voting
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
1. I only discovered this change when I pulled the master code when
adding FFI::addrValue().
Also, I have submitted this improvement proposal PR on May 20, 2022,
because I didn't push it forward because of my own network issues.
2. The reason why it is rude is because the implementation of the PR
seems to me to be lazy. Simply shielding things in order to implement
an RFC is like completing a KPI.
I don't know if you have any doubts about looking at the lot of code
like FFI::cdef()->new() in the FFI unit test file
In my opinion, this is an open source project, and if there is no good
beautiful solution, it is not an urgent matter, and it can be
postponed



Máté Kocsis <[email protected]> 于2024年7月6日周六 20:36写道:
>
> I am the author of that "stupid" commit and RFC
> (https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#fficast_ffinew_and_ffitype)
> which you are referring to. I can understand that you are unhappy about the outcome of the RFC,
> but I would have happily incorporated your feedback
> into the RFC if you had provided it earlier... Unfortunately, I didn't receive better
> suggestions about the FFI related parts, so I went ahead with what I
> had in mind.
>
> That being said, I support your RFC. It seems like a better solution than mine. However, I
> would ask you to change your tone to be less offensive,
> because rudeness is not a welcomed behavior on the mailing list, and by the way, we have the
> same ultimate goal of improving PHP, even if you are
> unsatisfied with a past decision of mine.
>
> Regards,
> Máté Kocis
>


Thread (10 messages)

« previous php.internals (#124251) next »