Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] SPL & PCRE as always enabled in core »

[RFC] SPL & PCRE as always enabled in core

php.internals

Marcus Börger

19 years ago
Hello internals, let's make ext/pcre and ext/spl first class core components and not allow to disable them. SPL: + influences a bunch of other stuff, and some extensions even behave different whether SPL is shared or built-in, this is hard to realize and understand for our users + was designed from the beginning to contain stuff that is standard in the oo world, so non standard stuff should be moved to specialized extensions like pecl/spl_types - yet another core component and special case - most important stuff could be moved to zend - but where to stop + well nothing in spl belongs into the engine, in the same way that nothing in ext/standard is in the engine. + zend engine has different license - i wouldn't allow the change + there is already too much in the engine, actually we should move stuff out of there - (oops/ouch, did i say this?) + spl only utilizes the engine, it does not influence modify anything there. + we want to be able to rely on SPL in run-tests.php PCRE: + used in a lot of stuff and influences stuff like SPL beep, go back to square one + is anybody not using this one, seriously? + other regex options suck + we want to be able to rely on PCRE in run-tests.php comments? Best regards, Marcus

Pierre Joye

19 years ago
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 iterator_count iterator_to_array spl_autoload_cal spl_autoload_extensions spl_autoload_functions spl_autoload_register spl_autoload_unregister spl_autoload spl_object_hash do outside ZE2. 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?
> + 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. --Pierre

Marcus Börger

19 years ago
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

Pierre Joye

19 years ago
Hello, On 6/5/07, Marcus Boerger <helly@php.net> wrote: I sniped the rest as we can argue endlessly about what should be in or out, I think I made my point :) However, in case I did not make it, here it is:
> Just a standard OOP function. Nothign that belongs into the engine.
If it is standard OO, it belongs to the engine, the core of the language. And the PHP internals developers (as for any language related decisions) should have the responsibility not a couple of extension maintainers. --Pierre

Marcus Börger

19 years ago
Hello Pierre, Tuesday, June 5, 2007, 11:21:48 PM, you wrote:
> Hello,
> On 6/5/07, Marcus Boerger <helly@php.net> wrote:
> I sniped the rest as we can argue endlessly about what should be in or > out, I think I made my point
> However, in case I did not make it, here it is:
>> Just a standard OOP function. Nothign that belongs into the engine.
> If it is standard OO, it belongs to the engine, the core of the > language. And the PHP internals developers (as for any language > related decisions) should have the responsibility not a couple of > extension maintainers.
While the engine changes the language, SPL only faciliates what the engine allows. For instance you can write any number of exceptions but SPL gives a nice number of default exception classes with a documented semantics. It is similar to the exception classes in C++/STL and there they are also not part of the language but of the extension (STL in this case). And I tried to do the same for PHP just as we did the same with ext/standard which hosts stuff that is part of the C API rahther than the C lnaguage. Where sizof/count is the exception to the rule. We have it in the ext while C/C++ have it in the language. Well it returns size_t which is part of the API rather than the language (damn broken design imo). Best regards, Marcus

Stanislav Malyshev

19 years ago
> let's make ext/pcre and ext/spl first class core components and not allow > to disable them.
Well, theoretically I can imagine reason why somebody would like to disable them - e.g., if I need super-high-performance server and I absolutely must squeeze out every last bit of cpu/memory usage _and_ I don't do neither SPL nor regular expressions - I might want to disable it. In any case, I see the reasons why we *want* it enabled. But I'd like to hear any reasons why we *need* it enabled - i.e. any vital stuff that can't work with SPL/PCRE disabled?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Pierre Joye

19 years ago
On 6/5/07, Stanislav Malyshev <stas@zend.com> wrote: I might want to disable it.
> In any case, I see the reasons why we *want* it enabled. But I'd like to > hear any reasons why we *need* it enabled - i.e. any vital stuff that > can't work with SPL/PCRE disabled?
I just listed two: - the array bugs in object properties. There is no other work around but to use ArrayObject. And this is rather critical. - The other functions I listed in my reply are also clearly ZE2 tasks (they all implement what is missing now in the engine). I can imagine a reason why one does not need PCRE. However it is already enable by default and is part of each distro default package as far I remember. --Pierre

Stanislav Malyshev

19 years ago
> - the array bugs in object properties. There is no other work around > but to use ArrayObject. And this is rather critical.
Could you elaborate - which bugs?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Pierre Joye

19 years ago
On 6/5/07, Stanislav Malyshev <stas@zend.com> wrote:
> > - the array bugs in object properties. There is no other work around > > but to use ArrayObject. And this is rather critical. > > Could you elaborate - which bugs?
A rude explanation was here: http://blog.thepimp.net/index.php/post/2006/11/28/comment-posting-fixed-and-warning-removed-and-some-overload-mess There is also a bug report about this problem, I just can't find it. --Pierre

Stanislav Malyshev

19 years ago
>> Could you elaborate - which bugs? > > A rude explanation was here: > > http://blog.thepimp.net/index.php/post/2006/11/28/comment-posting-fixed-and-warning-removed-and-some-overload-mess
I'm not sure I understand where is the bug. If your __get doesn't return by reference, it can't be modified. That's how it's supposed to work. If it returns by ref, it works.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Pierre Joye

19 years ago
On 6/5/07, Stanislav Malyshev <stas@zend.com> wrote:
> >> Could you elaborate - which bugs? > > > > A rude explanation was here: > > > > http://blog.thepimp.net/index.php/post/2006/11/28/comment-posting-fixed-and-warning-removed-and-some-overload-mess > > I'm not sure I understand where is the bug. If your __get doesn't return > by reference, it can't be modified. That's how it's supposed to work. If > it returns by ref, it works.
Please check the bugs database. There was numerous reports about this problem and there is no solution to use an object instead of an array (object being reference, that solves the issue). It is far from obvious that the current behavior is correct, read: it is not correct. However, I'm not arguing about why or how this bug should be fixed but that the only work 'round is in SPL. ArrayObject (and related) must be in Zend, it is a core feature. --Pierre

Stanislav Malyshev

19 years ago
> Please check the bugs database. There was numerous reports about this > problem and there is no solution to use an object instead of an array
I'm still not following, I tried modifying the example you gave making __get return by reference and it worked just fine. I would gladly look up the bug database, I just don't know what to look for since I still don't know what the problem is.
> However, I'm not arguing about why or how this bug should be fixed but > that the only work 'round is in SPL. ArrayObject (and related) must be > in Zend, it is a core feature.
I'm not so sure. For example, I'm sure sessions are user much more than ArrayObject, but they aren't.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Marcus Börger

19 years ago
Hello Stanislav, Wednesday, June 6, 2007, 9:06:13 AM, you wrote:
>> Please check the bugs database. There was numerous reports about this >> problem and there is no solution to use an object instead of an array
> I'm still not following, I tried modifying the example you gave making > __get return by reference and it worked just fine. I would gladly look > up the bug database, I just don't know what to look for since I still > don't know what the problem is.
>> However, I'm not arguing about why or how this bug should be fixed but >> that the only work 'round is in SPL. ArrayObject (and related) must be >> in Zend, it is a core feature.
> I'm not so sure. For example, I'm sure sessions are user much more than > ArrayObject, but they aren't. > -- > Stanislav Malyshev, Zend Products Engineer > stas@zend.com http://www.zend.com/
You are actually not allowed to change the signature. If you could add or drop & from the signature then there is a bug in the engine. That is what Pierre was referring to, the disability to change the signature. Best regards, Marcus

Stanislav Malyshev

19 years ago
> You are actually not allowed to change the signature. If you could add > or drop & from the signature then there is a bug in the engine. That is > what Pierre was referring to, the disability to change the signature.
You mean when you inherit class with __get defined? Why not?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Marcus Börger

19 years ago
Hello Pierre, it is neither a core feature nor does it blong into the engine. And the real solution would be: - proxies (object, property), (object, array index) - another interface, say ArrayAccessByRef which allows to deal with references, a few things can be done automatically but you can never solve all issues - unless you're using proxies - also another interface for IteratorByRef that has function &__current() might be interesting Now the proxies caneasily be done in userspace once we have the ability to overload get/set - i am actually thinking of doing something in pecl/spl_types. And later might be done in the engine completely. The interfaces however clearly belong into the engine. best regards marcus Wednesday, June 6, 2007, 9:02:00 AM, you wrote:
> On 6/5/07, Stanislav Malyshev <stas@zend.com> wrote: >> >> Could you elaborate - which bugs? >> > >> > A rude explanation was here: >> > >> > http://blog.thepimp.net/index.php/post/2006/11/28/comment-posting-fixed-and-warning-removed-and-some-overload-mess >> >> I'm not sure I understand where is the bug. If your __get doesn't return >> by reference, it can't be modified. That's how it's supposed to work. If >> it returns by ref, it works.
> Please check the bugs database. There was numerous reports about this > problem and there is no solution to use an object instead of an array > (object being reference, that solves the issue). It is far from > obvious that the current behavior is correct, read: it is not correct.
> However, I'm not arguing about why or how this bug should be fixed but > that the only work 'round is in SPL. ArrayObject (and related) must be > in Zend, it is a core feature.
> --Pierre
Best regards, Marcus

Frode E. Moe

19 years ago
On Tue, Jun 05, 2007 at 23:15:22 +0200, Pierre wrote:
> On 6/5/07, Stanislav Malyshev <stas@zend.com> wrote: > >> - the array bugs in object properties. There is no other work around > >> but to use ArrayObject. And this is rather critical. > > > >Could you elaborate - which bugs? > > A rude explanation was here: > > http://blog.thepimp.net/index.php/post/2006/11/28/comment-posting-fixed-and-warning-removed-and-some-overload-mess > > There is also a bug report about this problem, I just can't find it.
This sounds very much related to a (still open) bug report I posted http://bugs.php.net/bug.php?id=38102

Lukas Kahwe Smith

19 years ago
Stanislav Malyshev wrote:
> Well, theoretically I can imagine reason why somebody would like to > disable them - e.g., if I need super-high-performance server and I > absolutely must squeeze out every last bit of cpu/memory usage _and_ I > don't do neither SPL nor regular expressions - I might want to disable it.
These people can and will hack on the source anyways. They will do stuff like Yahoo is doing. They will not let themselves get stopped by anything we put in :) regards, Lukas

Ilia A.

19 years ago
The big reason for PCRE is the fact that other, rather important extensions such as filter depend on it. SPL is also used by other extensions, which could be a "need" reason. On 5-Jun-07, at 4:58 PM, Stanislav Malyshev wrote:
>> let's make ext/pcre and ext/spl first class core components and >> not allow >> to disable them. > > Well, theoretically I can imagine reason why somebody would like to > disable them - e.g., if I need super-high-performance server and I > absolutely must squeeze out every last bit of cpu/memory usage > _and_ I don't do neither SPL nor regular expressions - I might want > to disable it. > In any case, I see the reasons why we *want* it enabled. But I'd > like to hear any reasons why we *need* it enabled - i.e. any vital > stuff that can't work with SPL/PCRE disabled? > -- > Stanislav Malyshev, Zend Products Engineer > stas@zend.com http://www.zend.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Ilia Alshanetsky

Stanislav Malyshev

19 years ago
> The big reason for PCRE is the fact that other, rather important > extensions such as filter depend on it. SPL is also used by other > extensions, which could be a "need" reason.
But you can run PHP without filter extension.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Richard Lynch

19 years ago
On Tue, June 5, 2007 3:19 pm, Marcus Boerger wrote:
> let's make ext/pcre and ext/spl first class core components and not > allow > to disable them.
PCRE: +0.5 SPL: -1 (Just confuses me, never use it, don't need it) ymmv imho . . .
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Jani Taskinen

19 years ago
And to be absolutely clear about this: This will happen in HEAD (PHP 6) only. Right? :) --Jani On Tue, 2007-06-05 at 22:19 +0200, Marcus Boerger wrote:

Alexey Zakhlestin

19 years ago
On 6/6/07, Marcus Boerger <helly@php.net> wrote:
> + other regex options suck
I would argue that. mb_ereg (which is powered by oniguruma) seems to be way more interestingi (and it is faster too)
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Marcus Börger

19 years ago
Hello Alexey, but we already decided to obsolete mbstring in favor of ICU/PCRE in PHP 6. Also we have no control over mbstring's license because the license holder refuses to change mbstring library to PHP License. best regards marcus Wednesday, June 6, 2007, 4:32:11 PM, you wrote:
> On 6/6/07, Marcus Boerger <helly@php.net> wrote: >> + other regex options suck
> I would argue that. mb_ereg (which is powered by oniguruma) seems to > be way more interestingi (and it is faster too)
> -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/
Best regards, Marcus

Alexey Zakhlestin

19 years ago
I see… well, then I guess I have a reason to make oniguruma extension, which wouldn't be part of mbstring… but I guess I am getting offtopic here On 6/7/07, Marcus Boerger <helly@php.net> wrote: > Hello Alexey, > > but we already decided to obsolete mbstring in favor of ICU/PCRE in > PHP 6. Also we have no control over mbstring's license because the > license holder refuses to change mbstring library to PHP License. > > best regards > marcus > > Wednesday, June 6, 2007, 4:32:11 PM, you wrote: > > > On 6/6/07, Marcus Boerger <helly@php.net> wrote: > >> + other regex options suck > > > I would argue that. mb_ereg (which is powered by oniguruma) seems to > > be way more interestingi (and it is faster too) > > > -- > > Alexey Zakhlestin > > http://blog.milkfarmsoft.com/ > > > > > Best regards, > Marcus > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Cristian Rodriguez

19 years ago
On 6/6/07, Marcus Boerger <helly@php.net> wrote: Also we have no control over mbstring's license because the
> license holder refuses to change mbstring library to PHP License. >
why he has to ? the library is not derivated work of PHP, is a plain non-sense to ask other people libraries or work to be under the PHP license. If we use the same rationale, is like asking IBM to license ICU under the PHP license for use (or bundling) with PHP6.

Antony Dovgal

19 years ago
On 25.06.2007 06:17, Cristian Rodriguez wrote:
> On 6/6/07, Marcus Boerger <helly@php.net> wrote: > Also we have no control over mbstring's license because the >> license holder refuses to change mbstring library to PHP License. >> > > why he has to ? the library is not derivated work of PHP, is a plain > non-sense to ask other people libraries or work to be under the PHP > license. > > If we use the same rationale, is like asking IBM to license ICU under > the PHP license for use (or bundling) with PHP6.
The difference is that we do not ship ICU with PHP, but we do ship Oniguruma library.
-- Wbr, Antony Dovgal

Alexey Zakhlestin

19 years ago
As far as I understood, the problem is not oniguruma, which is BSD-licensed, but libmbfl, which is LGPL-licenses according to http://cvs.php.net/viewvc.cgi/php-src/ext/mbstring/README.libmbfl?revision=1.1&view=markup but according to http://sourceforge.jp/projects/php-i18n/ it is BSD-licensed now On 6/25/07, Antony Dovgal <antony@zend.com> wrote:
> > The difference is that we do not ship ICU with PHP, but we do ship Oniguruma library.
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Derick Rethans

19 years ago
On Tue, 5 Jun 2007, Marcus Boerger wrote:
> Hello internals, > > let's make ext/pcre and ext/spl first class core components and not allow > to disable them.
+1, and PCRE was already discussed for PHP 6 like this: http://php.net/~derick/meeting-notes.html#move-ereg-to-pecl regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org