I agree with Nikita and Sara here, interfacing between PHP and C however would be very important. My current UUID proposal for instance. Doing the bit shifting in PHP is a pain. Doing it in C is a breeze. However, doing the signatures and accessors in PHP would be MUCH simpler.
On 6/6/2017 2:43 PM, Nikita Popov wrote: > There are essentially only two good reasons for implementing functionality > in C: One is performance, the other is FFI. Unfortunately, the requirement > to use C for everything inside an extension means that we write a large > amounts of C code that does not fall into either of those categories. The > resulting code is hard to maintain, often subtly buggy and usually not > consistent with ordinary userland PHP code. Typical issues we see all the > time are bad or completely absent serialization support, lack of circular > garbage collection, crashes when the object is improperly initialized and > bugs appearing when internal classes are extended. I think that one of the main reasons for this is that lots of the C code implements this stuff again, custom made. Instead of just using the default stuff. Regarding the maintainer problem. PHP internals is a very hard turf and literally has a very bad reputation out there. It is very hard to get in, and it is very hard to contribute. Other communities (Go, Rust, ...) are much more welcoming. I think that the move to GitHub already helped a little, but it needs to open up even more. Internals needs to encourage, support, guide, and not simply turn down every idea. The internals book goes in the right direction here. Going more community with stuff like the mailing list (maybe a forum that is easier to join) and a chat (maybe something like gitter) are only tiny things that can help a lot here. We can learn from the other communities. I think that there are more than enough people out there who would be able to write some C. On 6/6/2017 5:55 PM, Sara Golemon wrote: > 100% this, though PHP's version of HNI will suffer a few shortcomings > due to the lack of a type_traits equivalent in C99. I'm not > suggesting we go C++11 just to get a better bridge, but it's a real > constraint in getting the same advantages that HNI has. Upgrading to C99 is imho long overdue! No clue why we are not finally doing the switch. I'd rather invest in Rust than C++11, seriously. C++ (regardless of version) is as painful as C after all. Sure, RAII solves all problems, but than we could also do Python instead of PHP if conventions is all we ask for. ;) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
