Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30087
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 85.214.80.207 cause and error)
Date: Tue, 5 Jun 2007 23:15:37 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1286789372.20070605231537@marcus-boerger.de>
To: Pierre <pierre.php@gmail.com>
CC: "Marcus Boerger" <helly@php.net>, internals@lists.php.net
In-Reply-To: <fe05d1540706051336u372d7ba3y3355a73c3e7ecd34@mail.gmail.com>
References: <1655508223.20070605221904@marcus-boerger.de> <fe05d1540706051336u372d7ba3y3355a73c3e7ecd34@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] SPL & PCRE as always enabled in core
From: helly@php.net (Marcus Boerger)

Hello Pierre,

Tuesday, June 5, 2007, 10:36:54 PM, you wrote:

> Hello,

> On 6/5/07, Marcus Boerger <helly@php.net> wrote:
>> Hello internals,
>>
>>   let's make ext/pcre and ext/spl first class core components and not allow
>>   to disable them.

> I fail to see what:
> class_implements
> class_parents
oh yeah there is alway an exception, we could move that to the engine.
But once again i think that we sactually should move stuff out of the
engine. We should seperate code and engine better.
> iterator_count
> iterator_to_array
standard functionality around iterators. they have nothing to do inside
the engine. they are like any function in ext/standard, only this is
about oop.
> spl_autoload_cal
> spl_autoload_extensions
> spl_autoload_functions
> spl_autoload_register
> spl_autoload_unregister
> spl_autoload
all discussable as this really influences the engines behavior. The
reason was actually to be able to disable it be disabling SPL. Now if
we disallow disabling SPL we might eventually move all of tese into the
engine. But then once again. We should not move stuff into but out of
the engine.
> spl_object_hash
Just a standard OOP function. Nothign that belongs into the engine.

All in all it appears we have a different point of view. I for one
would prefer having a seperation between engine and non engine stuff.
Where the Interfaces Iterator, IteratorAggregate, Traversable and the
classes stdClass and exception are the bridges between engine and
runtime system. As far as i get your point it is about keeping essential
core and core/engine influencing stuff into the engine.

I think everyone should answer the following question for him/herself:
Where do the array functions (including size) belong. Into the engine
or in ext/standard? If the latter, where does standard object stuff
belong the engine or ext/spl and where are the limits?

> ArrayObject is a must have to fix a couple of important issues with
> object properties and array. It is also a powerful way to work with
> arrays.

> Iterators are part of any modern language. They are often nicely
> integrated with the core of its language. Why should they be
> maintained in an extension in PHP?

because imho that is the way PHP is designed. You put stuff that belongs
together into an extension and assign responsibilities.

>> + zend engine has different license - i wouldn't allow the change

> Is it a no-no to any move? I would start to seriously worry about SPL if yes.

It often has been a no-no in the past. And that resulted in a bunch of
function pointers inside the engine. Like error reporting or spprintf.
Furthermore it resulted in stuff like TSRM being seperate.

Best regards,
 Marcus