Hi Mike,
Instead I replied because your email strongly implied (stated?) that "deprecation
required removal"
I stand by that interpretation, which while not universal is very widely
used, and I think is more useful than a general hint at "bad practice".
You spend most of your e-mail seeming to argue against it, and then seem
to say that actually you do agree with it after all, and all you're
saying is that sometimes the deprecation period should be longer:
I am not advocating that. I am advocating we should consider making it:
"features that are strongly discouraged will*probably* be removed in the next major
version, but in some cases may be retained for one or more major versions."
I'm totally OK with that.
I do think that there should be a clear *plan* for removing each
deprecated feature, though. That plan might be "deprecate in 8.1, and
examine prior to 9.0 whether usage has dropped / the alternatives are
mature / etc". It might flat out be "deprecate in 8.1, but don't remove
until 10.0".
Otherwise, the message becomes "this feature is kind of bad, and at some
point we might decide to drop it without further notice, but actually we
might not, so no hurry to remove it", which I just think isn't that helpful.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
