> On 21 Apr 2022, at 17:32, Andreas Leathley <a.leath...@gmx.net> wrote:
>
>>> There is another 3.5 years until PHP 9 is likely to come out, which is a
>>> lot of time for people to adjust their codebase. I could even see an
>>> argument for not promoting it to a fatal error in 9.0 if so many people
>>> need more time.
>>
>>
>> If it's deprecated, that is an intent to break... and if no other solutions
>> present themselves, and the vote for this RFC fails... why would it be
>> delayed? It will then be clear the Internals developers want this (they
>> would have made an informed choice, and put their name to it).
>
> A deprecation notice is fairly harmless. If in two years many projects and
> many developers say that they need more time to fix these deprecations and
> promoting them to errors would cause a lot of problems, then it would be easy
> to prolong the period where it is only a deprecation with a small RFC. By
> then more people will know if they are impacted, many frameworks will have
> updated, and there will be a clearer picture if this is such a big deal or
> not. Right now this is not clear - I doubt most projects are using PHP 8.1,
> not even all frameworks/libraries are compatible to PHP 8.1.
You're right, I am working with a few development teams that are simply not
upgrading to 8.1 at the moment, they don't have the time to fix this issue...
two are using set_error_handler() to ignore this specific deprecation notice,
and one team has moved over, but they are still finding these issues ~6 months
later.
>> Are you going to suggest any improvements? what have I missed? I'm trying to
>> keep it short, because I know long RFC's can be a problem.
>
> An RFC should cover the discussions held on this mailing list. From the RFC
> howto:
>
> "Update your RFC to document all the issues and discussions. Cover both the
> positive and negative arguments."
>
> Do you honestly believe you have done that? I have tried to discuss some
> counterpoints and alternatives to your proposal, but none are mentioned in
> the RFC. I also don't see the discussion points of other people in the RFC.
> None of the alternatives to your proposal are mentioned in the RFC - like
> changing the internal functions to accept null instead. There have been quite
> a few suggestions and arguments made so far, and I don't see them in the RFC.
I'll ask again, what have I missed? as in, please, give me details.
Last time you vaguely said that "George Peter Banyard wrote some extensive
arguments", I spent at least an hour going though every single point (again),
and this time I listed them out for you, and you ignored that, not even an
apology.
The only point you made in that last paragraph is "changing the internal
functions to accept null", it's already there, under the heading "Rejected
Features", which includes the link to the RFC I created, and the reason it was
rejected. That reason is also noted in the second paragraph of the Introduction.
> I have discussed RFCs with a few people on this mailing list, sometimes with
> very different opinions about a topic, and not always was there a resolution
> to the topic at hand. Yet the discussions with you have been the most
> frustrating so far, because you say you are open to arguments and proposals,
> yet you do not seem to consider them at all - yet you really seem to believe
> you are totally open-minded. I have been impressed by a few people on this
> mailing list who I disagreed with wholeheartedly, because I noticed with how
> much care they tried to relay disagreeing arguments and other proposals in
> the RFC and how balanced the RFCs were at the end. Your RFC seems totally
> incomplete to me and mainly based on your made-up opinion. But at this point
> I don't think I will get through to you in any way, which is why I will step
> out of this conversation. If the RFC comes to a vote in the current
> conditions though I will raise an objection that it does not represent the
> discussions held on this mailing list and should be disregarded because of
> that.
I have no idea how to respond to this, I have spent a considerable amount of
time carefully reading your 5 emails, responding to every single point you
raised (which you simply ignore), ensuring all points are in my RFC, and this
is your attitude? no apology, no thanks, just vague complaints and insults?
If you have any objection that is not already noted in the RFC, please, let me
know what it is... maybe "Andreas does not like the wording in this RFC, or the
stats provided, but does not provide any alternative"?
Craig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
