Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC]I'd like to see the RFCs that deprecate the FFI non-static approach start voting »

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

php.internals

€– ”k”k

2 years ago
My Submit RFC: https://wiki.php.net/rfc/ffi-non-static-deprecated Since no one responded to the first announcement, I am not sure if anyone agrees, so I will announce it again。 Since this RFC is the opposite of a PR, and the PR has already been merged and is expected to be released in PHP 8.4, can the PR be revoked first? Or do you all agree with the stupid PR?

shinji igarashi

2 years ago
Hi! I am rather more in favour of what you are proposing than the removal of static calls to FFI methods. In my opinion, it would be possible to drop the deprecation if it is agreed in the RFC process. The static access to FFI methods is not yet a feature actually removed, and I think it may even be possible to remove the deprecation in a point release of 8.3. I am a little more worried about the way you communicate than the content of your proposal. For example, in my opinion, "stupid" is too strong a word for the tone of language typically found in this internals ML. If you have no intention of ridiculing the person who proposed deprecation or people who voted yes to the proposal, and the strong language was used just because of the language barrier, it would be probably better to make that clear. Perhaps no one cares about trivial wording. Personally I don't care. But if by any chance strong wording prevents constructive discussion, no one will be happy.
-- Shinji Igarashi 2024年7月6日(土) 11:17 chopins xiao <chopins.xiao@gmail.com>:

€– ”k”k

2 years ago
The reason I'm not so polite is because I'm so angry. Firstly, the Deprecate functions with overloaded signatures RFC's approach to FFI recommendations is unfounded, and secondly, the PR commit(https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8) has not been voted on by the RFC, and the implementation is very simple and crude, and does not solve the problem that FFI's API is not so elegant （At the very least, there are shortcomings such as complicated API calls, mixed use of multiple types of functions, and reduced performance）. There are so many masters,I don't understand why it was merged. The commit implementation was not voted on, and it is possible to withdraw it first.

Saki Takamachi

2 years ago
Hi,
> The reason I'm not so polite is because I'm so angry. Firstly, the Deprecate functions with overloaded signatures RFC's approach to FFI recommendations is unfounded, and secondly, the PR commit(https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8) has not been voted on by the RFC, and the implementation is very simple and crude, and does not solve the problem that FFI's API is not so elegant （At the very least, there are shortcomings such as complicated API calls, mixed use of multiple types of functions, and reduced performance）. > There are so many masters,I don't understand why it was merged. The commit implementation was not voted on, and it is possible to withdraw it first.
If I'm not misunderstanding something, they were voted on. https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures Regards, Saki

Saki Takamachi

2 years ago
Hi,
>> The reason I'm not so polite is because I'm so angry. Firstly, the Deprecate functions with overloaded signatures RFC's approach to FFI recommendations is unfounded, and secondly, the PR commit(https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8) has not been voted on by the RFC, and the implementation is very simple and crude, and does not solve the problem that FFI's API is not so elegant （At the very least, there are shortcomings such as complicated API calls, mixed use of multiple types of functions, and reduced performance）. >> There are so many masters,I don't understand why it was merged. The commit implementation was not voted on, and it is possible to withdraw it first. > > If I'm not misunderstanding something, they were voted on. > > https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures > > Regards, > > Saki
I may have misunderstood what you were saying. I'm starting to get a little confused. What exactly do you mean by voting on a commit? Regards, Saki

Niels Dossche

2 years ago
On 06/07/2024 11:55, Saki Takamachi wrote:
> Hi, > >>> The reason I'm not so polite is because I'm so angry. Firstly, the Deprecate functions with overloaded signatures RFC's approach to FFI recommendations is unfounded, and secondly, the PR commit(https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8) has not been voted on by the RFC, and the implementation is very simple and crude, and does not solve the problem that FFI's API is not so elegant （At the very least, there are shortcomings such as complicated API calls, mixed use of multiple types of functions, and reduced performance）. >>> There are so many masters,I don't understand why it was merged. The commit implementation was not voted on, and it is possible to withdraw it first. >> >> If I'm not misunderstanding something, they were voted on. >> >> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures >> >> Regards, >> >> Saki > > I may have misunderstood what you were saying. > > I'm starting to get a little confused. > What exactly do you mean by voting on a commit? > > Regards, > > Saki
They think the PR is not part of the RFC and is landing in 8.4. The PR is in fact already part of 8.3 and was voted on by the RFC that Saki pointed out. Regards Niels

Jordan LeDoux

2 years ago
On Sat, Jul 6, 2024 at 1:09 AM chopins xiao <chopins.xiao@gmail.com> wrote:
> The reason I'm not so polite is because I'm so angry. Firstly, the > Deprecate functions with overloaded signatures RFC's approach to FFI > recommendations is unfounded, and secondly, the PR commit( > https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8) > has not been voted on by the RFC, and the implementation is very simple and > crude, and does not solve the problem that FFI's API is not so elegant （At > the very least, there are shortcomings such as complicated API calls, mixed > use of multiple types of functions, and reduced performance）. > There are so many masters,I don't understand why it was merged. The commit > implementation was not voted on, and it is possible to withdraw it first. > >
Very unfortunate. Might have a solid technical case, but you: 1. Called someone who contributed to the project with actual code stupid because they didn't do what you'd prefer. 2. Called the implementation they provided "simple and crude". 3. Asked about this on GitHub and were told it was voted on, but are bringing this anyway: https://github.com/php/php-src/issues/14608 4. Opened this ML thread with a request/demand to revert the commit simply because you want to talk about your proposal. 5. Did all of the above without any indication that you could provide a non-"simple and crude" implementation since you are apparently better at it than everyone else who contributes. Regardless of the technical merits, you're not going to win many discussions like that. Jordan

Máté Kocsis

2 years ago
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

John Coggeshall

2 years ago
> 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. >
I personally would love to see someone give FFI more love than it's received. It's got so much potential if it can become easier and less clunky / more straightforward to use. It seems like this particular functionality was implemented but it appears (at least to me?) that it doesn't have a clear caretaker who is putting in the work to really polish it up, improve the documentation, and make it accessible to the masses. I know I'd love to use it rather than having to write or use a custom PECL extension, but any time I've tried to play with it the barrier was too high to be productive. Tone aside (I agree calling things stupid isn't productive.. this isn't the linux kernel mailing list circa 2010), it seems like there is a lot of frustration being caused by this lack of attention.. It feels like an aspect of PHP no one uses because most don't understand how to use it well -- Perhaps Chopins would you be willing to lead that charge? I can't imagine there are many voters on this list who even would have a strong opinion at this point on any changes we do make to improve the situation, so it seems like any well thought out proposal would likely succeed. Unless of course I'm grossly underestimating the popularity of FFI today.. in which case perhaps I should take my thoughts to the docs mailing list.. John

€– ”k”k

2 years ago
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 <kocsismate90@gmail.com> 于2024年7月6日周六 20:36写道：