Re: [PHP-DEV] SPL development interest

  110184
May 16, 2020 14:37 jakob@givoni.dk (Jakob Givoni)
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
  110208
May 19, 2020 00:23 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
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
  110274
May 25, 2020 20:26 benas.molis.iml@gmail.com (Benas IML)
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.