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.
On Wed, Jan 10, 2018 at 6:27 AM, Michael Morris <tendo...@gmail.com> wrote: > On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf <ras...@lerdorf.com> > wrote: > > > > > The difference here is that the end syntax is something like 10% of the > > problem. 90% of it is fitting it into the engine in an efficient manner > > giving that it is affecting the very core of the engine. An RFC on this > > issue that doesn't address the bulk of the problem isn't all that > helpful. > > > > > It makes absolutely NO sense to do that 90% of the work to have it all > burned up when the proposal fails to carry a 2/3rds vote because the syntax > is disliked. > > Also, drawing the architectural drawings for a skyscraper is also like only > 10% of the work, but it's a damn important 10%. > > That the implementation will be a major pain in the ass to do is all the > more reason to create and pass a planning RFC before doing any related > code/implementation RFC's. It will encourage people to do the research to > try to figure out how to get this done because they know the syntax is > approved and they aren't fiddling around in the dark trying to figure out > how to do something that may not be accepted for inclusion at all, which is > a huge waste of time. >