On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch <ryan.jentz...@gmail.com> wrote:
> I agree with Michael (to a large degree) and I think I see clearly > Michael's point: > Under the current system I will NEVER create an RFC (or find someone with > the Zend engine coding chops to help me) because the RISK vs. REWARD with > the current RFC system is too likely to be a colossal waste of everyone's > time. > Currently the tail wags the dog (implementation details govern top level > policy). The current process nearly insists I spend valuable time coding up > front with a good chance that if/when the RFC goes up for a vote someone > will still be bleating about syntax, or using tabs vs. spaces, or some > other minor detail -- with a 2/3 vote needed it may shoot all my > preliminary hard work to hell. No thanks. There is a middle ground here. I agree that doing months of work on a rock-solid implementation doesn't make sense if you don't know the RFC will pass. On the other end of the spectrum, RFCs that are essentially feature requests with no specifics on the actual implementation also don't make any sense. A good RFC strikes a happy balance between the two. For many/most things, the actual work in figuring out the implementation isn't that bad. As Sara said, a full implementation isn't needed, but a rough sketch of what changes are needed along with their potential impact on the existing code definitely is. And yes, unfortunately, if your RFC touches the basic building block of PHP, the zval, then that rough sketch becomes even more important. If you stay away from trying to change a 25-year old loosely typed language into a strictly typed one, then the RFC becomes much simpler. -Rasmus
