# [RFC] SPL & PCRE as always enabled in core - Thread: https://externals.io/message/30079 - Original archive: https://news-web.php.net/php.internals/30079 - Started by Marcus Boerger on 2007-06-05T20:19:04+00:00 - Messages: 29 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/30079.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #30079 — Marcus Boerger — 2007-06-05T20:19:04+00:00 URL: https://externals.io/message/30079#30079 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 --- ## #30080 — Pierre — 2007-06-05T20:36:54+00:00 URL: https://externals.io/message/30079#30080 · In reply to: #30079 Hello, > 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 --- ## #30081 — Stanislav Malyshev — 2007-06-05T20:58:12+00:00 URL: https://externals.io/message/30079#30081 · In reply to: #30079 > 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/ --- ## #30082 — Pierre — 2007-06-05T21:03:02+00:00 URL: https://externals.io/message/30079#30082 · In reply to: #30081 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 --- ## #30083 — Lukas Kahwe Smith — 2007-06-05T21:08:55+00:00 URL: https://externals.io/message/30079#30083 · In reply to: #30081 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 --- ## #30085 — Stanislav Malyshev — 2007-06-05T21:12:53+00:00 URL: https://externals.io/message/30079#30085 · In reply to: #30082 > - 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/ --- ## #30086 — Pierre — 2007-06-05T21:15:22+00:00 URL: https://externals.io/message/30079#30086 · In reply to: #30085 > > […] > > 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 --- ## #30087 — Marcus Boerger — 2007-06-05T21:15:37+00:00 URL: https://externals.io/message/30079#30087 · In reply to: #30080 Hello Pierre, Tuesday, June 5, 2007, 10:36:54 PM, you wrote: > Hello, > > > […] > 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. > > […] > 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 --- ## #30089 — Pierre — 2007-06-05T21:21:48+00:00 URL: https://externals.io/message/30079#30089 · In reply to: #30087 Hello, 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 --- ## #30090 — Stanislav Malyshev — 2007-06-05T21:23:42+00:00 URL: https://externals.io/message/30079#30090 · In reply to: #30086 > > […] > > 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/ --- ## #30091 — Marcus Boerger — 2007-06-05T21:29:15+00:00 URL: https://externals.io/message/30079#30091 · In reply to: #30089 Hello Pierre, Tuesday, June 5, 2007, 11:21:48 PM, you wrote: > Hello, > > 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: > > […] > 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 --- ## #30093 — Richard Lynch — 2007-06-05T21:49:09+00:00 URL: https://externals.io/message/30079#30093 · In reply to: #30079 > 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? --- ## #30095 — Frode E. Moe — 2007-06-05T22:05:52+00:00 URL: https://externals.io/message/30079#30095 · In reply to: #30086 > > > […] > > 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 --- ## #30096 — Ilia Alshanetsky — 2007-06-05T22:06:57+00:00 URL: https://externals.io/message/30079#30096 · In reply to: #30081 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. > > […] > > 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/ > > -- > > > Ilia Alshanetsky --- ## #30099 — Stanislav Malyshev — 2007-06-05T22:32:06+00:00 URL: https://externals.io/message/30079#30099 · In reply to: #30096 > 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/ --- ## #30103 — Pierre — 2007-06-06T07:02:00+00:00 URL: https://externals.io/message/30079#30103 · In reply to: #30090 > > […] > > 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 --- ## #30104 — Stanislav Malyshev — 2007-06-06T07:06:13+00:00 URL: https://externals.io/message/30079#30104 · In reply to: #30103 > 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/ --- ## #30105 — Marcus Boerger — 2007-06-06T07:13:47+00:00 URL: https://externals.io/message/30079#30105 · In reply to: #30103 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: > > > […] > 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 --- ## #30106 — Marcus Boerger — 2007-06-06T07:15:17+00:00 URL: https://externals.io/message/30079#30106 · In reply to: #30104 Hello Stanislav, Wednesday, June 6, 2007, 9:06:13 AM, you wrote: > > […] > 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. > > […] > 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 --- ## #30108 — Stanislav Malyshev — 2007-06-06T07:52:51+00:00 URL: https://externals.io/message/30079#30108 · In reply to: #30106 > 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/ --- ## #30111 — Jani Taskinen — 2007-06-06T10:30:40+00:00 URL: https://externals.io/message/30079#30111 · In reply to: #30079 And to be absolutely clear about this: This will happen in HEAD (PHP 6) only. Right? :) --Jani > 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 --- ## #30116 — Alexey Zakhlestin — 2007-06-06T14:32:11+00:00 URL: https://externals.io/message/30079#30116 · In reply to: #30079 > + 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/ --- ## #30120 — Marcus Boerger — 2007-06-06T21:12:17+00:00 URL: https://externals.io/message/30079#30120 · In reply to: #30116 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: > > > […] > 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 --- ## #30121 — Alexey Zakhlestin — 2007-06-07T09:43:29+00:00 URL: https://externals.io/message/30079#30121 · In reply to: #30120 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 > 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: > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #30136 — Derick Rethans — 2007-06-11T06:14:39+00:00 URL: https://externals.io/message/30079#30136 · In reply to: #30079 > 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 --- Next page: https://externals.io/message/30079.md?page=2