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?
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:
My Submit RFC:
https://wiki.php.net/rfc/ffi-non-static-deprecatedSince 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?
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.
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
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
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
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:
- Called someone who contributed to the project with actual code stupid
because they didn't do what you'd prefer. - Called the implementation they provided "simple and crude".
- 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 - Opened this ML thread with a request/demand to revert the commit simply
because you want to talk about your proposal. - 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
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
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
- 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. - 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写道：
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