Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110208
Message-ID: <d60461253e5a9680774cf243fee1092882c5a880.camel@schlueters.de>
To: Jakob Givoni <jakob@givoni.dk>, Arnold Daniels <arnold@jasny.net>
Cc: Dan Ackroyd <Danack@basereality.com>, php internals
	 <internals@lists.php.net>
Date: Tue, 19 May 2020 02:23:44 +0200
In-Reply-To: <CAJmjfvUC_uL0qJkX7pCixJSFZUjT1UieL6GdLKu13eKbUU1-9g@mail.gmail.com>
References: 
	<CAJmjfvU1z2C6r0XCnwZsuDFMy9LBdAaH-Uw8dQJgtAGuOe7H=g@mail.gmail.com>
	 <CA+kxMuTCpUo4TKuC=cdTdv1p7AAc9-vdAQUq9vrf02+0J9aZRg@mail.gmail.com>
	 <CANZOY=BcGNSsc1bpKYVWdJOLVxSpr1uTd2YhXK9Oom+8i_-61g@mail.gmail.com>
	 <CAJmjfvUC_uL0qJkX7pCixJSFZUjT1UieL6GdLKu13eKbUU1-9g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SPL development interest
From: 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