Pierre Joye wrote on 25/03/2015 13:19:
On Wed, Mar 25, 2015 at 1:35 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
Levi Morrison wrote on 24/03/2015 20:35:
On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobw...@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do
this
without RFC. Minimal self-contained changes don't need a RFC and can go
as
well into alpha/beta phase without issues.
Sorry, I don't understand when a change is supposed to require an RFC or
not, and when it can come after feature freeze or not. Is it written
somewhere ? What is the definition of a 'minimal self-contained' change
?
Why is it different if it belongs to an extension ?
I may be wrong but the proposed change is not what I call a 'minimal
self-contained' change and there's a clear BC break. I'd love it to be
part
of 7.0 but I would first appreciate to be sure the rules are the same
for
everyone.
Agreed, this is quite a major feature, and pretty much everything in PHP
is
an "extension" as far as the architecture is concerned.
While I agree it would be great to phase this functionality out, I don't
see
how that can be done without an RFC.
If we deprecate it I am fine with doing this without an RFC. Removing
it would need an RFC in my opinion.
But a decision to "deprecate" just means "remove, but not yet", so either
way we're making a decision about what features the language will have, and
skipping the established process in the name of convenience.
I wonder if people are confusing the fact that they don't like this feature,
and don't need it, with it being a "minor" feature. There are definitely
people out there using it, and the impact of removing it may be considerable
to them. There is also the question of what we are deprecating it in favour
of.
To me it is buggy. It is a partial implementation to begin with. An
app has no idea what is supported or not, custom extensions will call
native APIs without taking care about what the PHP exposed functions
are.
I agree with the reasoning, but again, that's justification for its
removal, not justification for skipping the RFC process.
I think there should be a quick RFC collecting this reasoning, and a
formal invitation for contrary opinions, to avoid accusations that it
was slipped in the back door. If there really is no opposition, the RFC
will record that the vote was unanimous, and be a point of reference to
anyone looking for more explanation than the manual provides.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
