Márcio,


I hope to be able to work on an actual implementation and have something by
the end of the upcoming week, allowing us all to experiment.

Other than tweaking the conversion table, which based on the feedbacks I *
*believe** can be done in a way everyone can live with – I agree that the
biggest open question is how we deal with internal functions.



Also note that the, the 2nd proposed option in the RFC (“Emit E_DEPRECATED
in 7.0, move to E_RECOVERABLE_ERROR in v7.1 or v8.0”) – of marking
newly-rejected-conversions as E_DEPRECATED is not considered as a BC break
IMHO.  The code would still work, and the likelihood that something bad was
legitimately found is pretty high.



Given the compressed timeline, I wanted to gauge the general response as
soon as possible, and also start the RFC discussion process as soon as
possible, which meant we couldn’t include the implementation to go along
with it.



Two more things regarding the competing RFC – it’s still alive, and being
promoted for PHP 7.0;  And while it doesn’t create a huge BC break, it
allows developers to selectively create localized BC breaks, on a per file
basis.



Thanks for the feedback!


Zeev



Thanks for your effort and for proposing the RFC so quick. But indeed, as
you said, this is really premature.

According to my interpretation the RFC proposes a potentially huge bc break
on internal functions usage while the competing (recently withdraw) RFC was
BC compatible regarding this. Having this proposal without a working patch,
so we can try the real impact it could have before form opinions, frankly,
doesn't sound like a good idea.

I know it's still a draft but, considering the RFC is aimed to v7.0, I hope
to see a working implementation before the feature freeze just like what
was exemplary made with the other previous withdraw proposals.

Thanks,

Márcio

Reply via email to