Hello Pierre, Tuesday, June 5, 2007, 10:36:54 PM, you wrote:
> Hello, > On 6/5/07, Marcus Boerger <[EMAIL PROTECTED]> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
