Thank you guys for your insights! You pretty much confirmed my fears about the SPL extension. The reason I was wondering about it was mostly for understanding where one would put Classes, Interfaces and Traits that should be essential parts of the language. F.ex. it seems the Countable interface should have been in the core together with Traversable and Serializable, especially since count() knows about Countable and is part of the core. It seems there are only 3 classes that are part of the core: Closure, Generator and WeakReference. And no traits, right? Anyway, thanks again, I'm learning. Jakob
On Sat, 2020-05-16 at 16:37 +0200, Jakob Givoni wrote:> The reason I was wondering about it was mostly for understanding > where > one would put Classes, Interfaces and Traits that should be essential > parts of the language. > F.ex. it seems the Countable interface should have been in the core > together with Traversable and Serializable, especially since count() > knows about Countable and is part of the core. > > It seems there are only 3 classes that are part of the core: Closure, > Generator and WeakReference. > And no traits, right?Not sure what "the core" might be. Where code lives has a few technical arguments, but also some mindset of the developer aspects. Some aspects, sometimes anecdotally: * Anything in Zend/ may not directly depend on anything elsewhere. In the past there was even a buildsystem maintained so one could do `cd Zend; ./buildconf; ./configure; make` and then had a libzend.so for whatever purpose, but that was removed "recently" - https://github.com/php/php-src/blob/PHP-7.3/Zend/buildconf is gone in master) * In consequence anything language related like Closure has to live in Zend/ (the engine must be able to create those when seeing related syntax) * If it can live elsewhere, probably it should * ext/standard is the classic anything which goes nowhere else" * main/ has a few things, mostly stream related, but usually should have more the glues and internals than "directly" called code * ext/spl was to large parts helly's playground for more object oriented and functional things * If a feature is a bit larger it can be good to encapsle it, for instance json_encode and json_decode could live in ext/standard but since it's quite a bit of code separating in it's own extension makes sense * ext/json being possible to be disable means that other extensions can't rely on it being there to 100% * Similar historically date routines had been in ext/standard but when Derick created the new Date classes this was so much, that splitting of made sense * Reflection initially lived in Zend/ as it gives out quite some engine details, however write access to the engine is kept a bit more restricted than elsewhere and when I sent too many patches helly at some point decided to move it from Zend/ to ext/reflection so I could directly commit ( https://github.com/php/php-src/commit/7cb0480d0 ) johannes
Hey, yes, there are no traits at the moment. Also, in PHP 8 there was `WeakMap` class added to the core as well. Best regards, Benas Seliuginas P.S: your email is marked as spam for me and probably for everyone else too, so most of the internals probably missed your emails. Try using a gmail-based email account instead since those tend to passthru spam protection better.