> On May 8, 2020, at 15:10, CHU Zhaowei <m...@jhdxr.com> wrote: > > This idea has been brought up during the RFC for preloading. I think it's a > good idea because it will make the c part smaller, and reduce the cost of > maintenance. The question is, where should we start with? the existing > functions in C work well, why should we put effect to convert them back to > php. For new functions, it means more workload. The RFC's author has to > convince others that this feature is better to implement in PHP rather than > in C.
I agree that the RFC for this must make a compelling case for it, since it will require work in the core to make this possible, and that work probably won’t be trivial. As for porting code from C into PHP, I don’t think it has to be done en masse. I would start with no more than a handful of simple functions (maybe even `uniqid()`, since that’s where this discussion began) that would act as examples. Once the capability for this is implemented and shipped, I think finding contributors to port functionality on a function-by-function basis won’t be difficult, since more folks in the community will be able to contribute, but it also doesn’t need to be done at a rapid pace, either. The primary benefit of porting from C to PHP in the core, IMO, is for greater opportunities for contributions and maintenance from the community. Cheers, Ben
signature.asc
Description: Message signed with OpenPGP
