Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP6 todo list »

PHP6 todo list

php.internals

Lukas Kahwe Smith

19 years ago
Hi, Going over the todo list I wanted to bring up a few topics once again for review/discussion (not flaming): http://oss.backendmedia.com/PhP60 # Unicode 3. remove old parameter parsing API and replace with one that supports unicode related functionality I just want to remind that when we made some changes to the parameter parsing API's last time it created some BC issues (like with array_merge() ..) 5. add unicode to pdo (wez) Maybe one place where IBM could step up, seeing that they are putting a lot of resources into their PDO drivers. # cleanups 4. safe_mode/open_basedir 1. remove safe mode and throw E_CORE_ERROR when set 2. unbundle safe_mode_exec_dir from safe_mode and keep it (rasmus) (take a look at this patch too) 3. new ini option: open_basedir_for_include which would allow using include/require(_once) on an expanded set of directories (sara) Whats the state here. I remember that there was still a fair bit of back and forth on this point. 9. remove zend.ze1_compatibility mode and throw E_CORE_ERROR when set DONE (dmitry) Same here. Gone for good? # PECL 3. regexp 1. make ereg an extension 2. PCRE extension will not be allowed to be disabled. 3. core of PHP should be made to work with PCRE so that we can safely disable ereg 4. unbundle the regex library We had a short discussion on this one not too long ago. 5. move mime_magic from the core to PECL 6. fileinfo 1. move the Fileinfo extension to the core, and enable it by default. 2. Fileinfo extension should be updated to only load its database once on MINIT. Didn't we fast track these two to 5.x? 7. ext/soap 1. ext/soap will be turned on by default 2. implement some of the security extensions to ext/soap 3. watch axis2 based implementation development I am guessing the security stuff could take a bit to implement. Does anyone feel "responsible" for this item? Engine additions 2. add a new 64bit integer that is always 64bits regardless of platform with the cast name for this new type is (int64) and internally we use IS_INT64 and RETURN_INT64 etc.. Are we still on track with this one? 4. add an ifsetor() construct with the middle value for the ?: ternary operator dropped Kinda scared to mention this one. Me want very much though :) 6. speed up @-operator and ask andi for approval (ilia, marcus) 7. add ability to allocate persistent zvals in PHP. 8. add ZEND_ACC_READONLY (marcus) Just bringing those 3 up as a reminder. It sounds like 6. is done and just needs a nod? 7. needs someone breaking some brain cycles over and 8. is probably trivial to do ..? # OO changes 3. object casting to primitive types BC mess (derick) Derick could you elaborate on this one? 5. fix __toString() DONE (marcus) Didn't we fix this one in 5.x already? 6. add internal flag only to force calling of the parent constructor I guess we have something like this in PDO already. Personally I think we should have rather promoted the "factories" pattern for extensions as well. But if we have it for internals stuff, why not also for userland? 7. re-use the "static::" keyword to do runtime evaluation of statics. This is one of the most wanted features going from user feedback. 8. add namespace support (marcus, jessie) This topic still alive? 9. add support for type-hinted return values. Seems like quite a big feature in terms of changing PHP, but could be quite a nice feature for stuff like soap wsdl generation (though here we can always fallback on phpdoc parsing). # Other Additions/Changes 2. APC 1. include APC in the core distributions (turned off by default) and switch to mmap as default shared memory storage. 2. ability to move autoloaded main classes in apc's class lookup preventing the overhead of doing the inheritance process all the time. (marcus) Are we still on track with this one? I remember that Zeev said he was generally ok with this one, but wanted to ponder it some more. 3. include the patch' real-path fix from hardended php Wasn't this done already in 5.x? 4. include the protection against HTTP Response Splitting attacks (header() shouldn't accept multiple headers in one call) from hardended php Wasn't this done already in 5.x? 5. split allow_url_fopen into two distinct settings: allow_url_fopen and allow_url_include. If allow_url_fopen is off, then allow_url_include will be off too. 6. enable allow_url_fopen by default 7. disable allow_url_include by default Is this still going to happen? 8. add sand boxing if we have a rock solid implementation (sara) Sara, just making sure you are allocating brain cycles for this on a daily basis ;) 9. go over the engine and extensions and make sure only E_ERROR is used where the engine is in an unrecoverable state. Hmm, this sounds like a nice one to get your feet wet in internals development. Hope I have time to finish Sara's book on my USA trip that lasts until end of May. 11. kill "<%" but keep "<?". Sounds easy enough to do. Why not do it know, so that we can hear about the impact for users as early as possible. 12. prepare a patch that disallows mixing different open/close tags. (jani) Jani .. looks like you are back!? :) 17. Output Control 1. rewrite DONE (mike) 2. revisit existing output handlers (mike) I remember that Mike was a bit dissapointed with feedback on this one. Whats the status here Mike? 18. add php native mysql driver aka mysqlnd (georg, andrey) I guess there is a beta out now, which even works with PHP5. Maybe its time to move the code into phpcvs .. its PHP licensed anyways AFAIK. Finally here are some undiscussed items which should probably be discussed and dropped or added to the above list. I think we can probably through out the majority of these items fairly quickly. 1. reference mess (once and for all) (derick) 2. Only Unicode and binary string types. (andrei) 1. Unicode-related errors should be exceptions 2. keep user-visible API unified: no separate parse_url() for IDNA 3. hash hook or interface (george) 4. add autoconversion for parameter parsing api (marcus) 5. add a way to get the internal object directly by parameter parsing api (marcus) 6. get rid of *_ex() functons in engine where possible (marcus) 7. provide a a replacement for the GD extension, being maintained and easy to extend (pierre) 8. "ext/pimpmydate", new date/time features, real OO interface (pierre) 9. throwing exceptions in SoapServer? and catching them with SoapClient? (korving) 10. a non-bankers-round round() variant (korving) 11. being able to use array() when defining constants (korving) 12. regular expression switch-matching (korving) 13. add SRM (amico) 14. add support for dangling commas 15. soap is a cluster-fuck. fix it and add support for wsse/secext (george) 16. fix openssl/curl to use stream transports 17. provide a global __call for non existing functions (george) 18. replace flex with re2c (sascha) 19. reimplement ext/zlib based on pecl/http code (mike) 20. MFB add RFC1867 fileupload processing hook (stefan) 21. Replace flex/bison scripts with re2c/lemon ones as soon as re2c supports states like flex does. This will fix the memleak issues of the parser, make the lexer&parser threadsafe and reentrant and allows to use emalloc on temp blocks automatically. (marcus) regards, Lukas

Johannes Schlueter

19 years ago
Hi Lukas, On Thu, 2007-04-12 at 16:37 +0200, Lukas Kahwe Smith wrote:
> 4. safe_mode/open_basedir > 1. remove safe mode and throw E_CORE_ERROR when set > 2. unbundle safe_mode_exec_dir from safe_mode and keep it > (rasmus) (take a look at this patch too) > 3. new ini option: open_basedir_for_include which would allow > using include/require(_once) on an expanded set of directories (sara) > > Whats the state here. I remember that there was still a fair bit of back > and forth on this point.
At least safe_mode and magic_quotes are gone. I'm not sure about safe_mode_exec_dir or open_basedir_for_include.
> 9. remove zend.ze1_compatibility mode and throw E_CORE_ERROR when > set DONE (dmitry) > > Same here. Gone for good?
No. Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change on 2006/06/05 13:58:52. I didn't find the discussion but I remember there was some "When did we decide on that?" posting from Zeev.
> 4. add an ifsetor() construct with the middle value for the ?: > ternary operator dropped > > Kinda scared to mention this one. Me want very much though :) >
Marcus recently added a ?: Operator which isn't exactly the ifsetor but close to it. zend_language_parser.y revision 1.179 date: 2007/03/04 16:25:57; author: helly; state: Exp; lines: +4 -1 - Implement '?:' [DOC] "expr1 ?: expr1" is a shortcut for: "expr1 ? expr1 : expr2" as exists in gcc and discussed some time back. Note that this is not an implementation ifsetor($var, default). While ifsetor would not generate any message for non existing variables or array indices the ternary shortcut does. Also the ternary shortcut does a boolean evaluation rather then checking for isset(). That way ther ternary shortcut can work on any expression while ifsetor can only work on variables. Also to be silent one has do do: "@$expr1 ?: $expr2".
> 5. fix __toString() DONE (marcus) > > Didn't we fix this one in 5.x already?
Yes.
> 5. split allow_url_fopen into two distinct settings: allow_url_fopen > and allow_url_include. If allow_url_fopen is off, then allow_url_include > will be off too. > 6. enable allow_url_fopen by default > 7. disable allow_url_include by default > > Is this still going to happen?
That's in 5.2.0.
> 9. go over the engine and extensions and make sure only E_ERROR is > used where the engine is in an unrecoverable state. > > Hmm, this sounds like a nice one to get your feet wet in internals > development. Hope I have time to finish Sara's book on my USA trip that > lasts until end of May.
That should meanwhile be the case for most extensions. All said in my best knowledge and I removed the parts where I wasn't sure about the state :-) johannes

Johannes Schlueter

19 years ago
On Thu, 2007-04-12 at 17:52 +0200, Johannes Schlüter wrote:
> No. > Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change > on 2006/06/05 13:58:52. > I didn't find the discussion but I remember there was some "When did we > decide on that?" posting from Zeev.
Ah I'm sorry, reading is hard :-) The revert only was about the PHP 5 branch. Sorry for the wrong information. http://www.mail-archive.com/internals@lists.php.net/msg22098.html Would be the discussion if it still matters then :-) johannes

Marcus Börger

19 years ago
Hello Johannes, Thursday, April 12, 2007, 5:52:57 PM, you wrote:
> Hi Lukas,
> On Thu, 2007-04-12 at 16:37 +0200, Lukas Kahwe Smith wrote: >> 4. safe_mode/open_basedir >> 1. remove safe mode and throw E_CORE_ERROR when set >> 2. unbundle safe_mode_exec_dir from safe_mode and keep it >> (rasmus) (take a look at this patch too) >> 3. new ini option: open_basedir_for_include which would allow >> using include/require(_once) on an expanded set of directories (sara) >> >> Whats the state here. I remember that there was still a fair bit of back >> and forth on this point.
> At least safe_mode and magic_quotes are gone. I'm not sure about > safe_mode_exec_dir or open_basedir_for_include.
>> 9. remove zend.ze1_compatibility mode and throw E_CORE_ERROR when >> set DONE (dmitry) >> >> Same here. Gone for good?
> No. > Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change > on 2006/06/05 13:58:52. > I didn't find the discussion but I remember there was some "When did we > decide on that?" posting from Zeev.
I thought Zeev only brought it back for 5? We agreed for removing it in 6. If it is still there we drop it. And if someone brings it back he will get his access removed.
>> 4. add an ifsetor() construct with the middle value for the ?: >> ternary operator dropped >> >> Kinda scared to mention this one. Me want very much though :) >>
> Marcus recently added a ?: Operator which isn't exactly the ifsetor but > close to it.
No, ifsetor will always be faster. Even @?: isn't the same as there still error messages will be generated, just not send out.
> zend_language_parser.y revision 1.179 > date: 2007/03/04 16:25:57; author: helly; state: Exp; lines: +4 -1 > - Implement '?:' > [DOC] "expr1 ?: expr1" is a shortcut for: "expr1 ? expr1 : expr2" as > exists in gcc and discussed some time back. Note that this is not > an implementation ifsetor($var, default). While ifsetor would not > generate any message for non existing variables or array indices > the ternary shortcut does. Also the ternary shortcut does a > boolean > evaluation rather then checking for isset(). That way ther ternary > shortcut can work on any expression while ifsetor can only work on > variables. Also to be silent one has do do: "@$expr1 ?: $expr2".
Best regards, Marcus

Andrey Hristov

19 years ago
Hi Lukas, Lukas Kahwe Smith wrote:
> Hi, > > Going over the todo list I wanted to bring up a few topics once again > for review/discussion (not flaming): > http://oss.backendmedia.com/PhP60 > > # Unicode > > 3. remove old parameter parsing API and replace with one that > supports unicode related functionality > > I just want to remind that when we made some changes to the parameter > parsing API's last time it created some BC issues (like with > array_merge() ..) > > 5. add unicode to pdo (wez) > > Maybe one place where IBM could step up, seeing that they are putting a > lot of resources into their PDO drivers. > > # cleanups > > 4. safe_mode/open_basedir > 1. remove safe mode and throw E_CORE_ERROR when set > 2. unbundle safe_mode_exec_dir from safe_mode and keep it > (rasmus) (take a look at this patch too) > 3. new ini option: open_basedir_for_include which would allow > using include/require(_once) on an expanded set of directories (sara) > > Whats the state here. I remember that there was still a fair bit of back > and forth on this point. > > 9. remove zend.ze1_compatibility mode and throw E_CORE_ERROR when set > DONE (dmitry) > > Same here. Gone for good? > > # PECL > > 3. regexp > 1. make ereg an extension > 2. PCRE extension will not be allowed to be disabled. > 3. core of PHP should be made to work with PCRE so that we can > safely disable ereg > 4. unbundle the regex library > > We had a short discussion on this one not too long ago. > > 5. move mime_magic from the core to PECL > 6. fileinfo > 1. move the Fileinfo extension to the core, and enable it by > default. > 2. Fileinfo extension should be updated to only load its > database once on MINIT. > > Didn't we fast track these two to 5.x? > > 7. ext/soap > 1. ext/soap will be turned on by default > 2. implement some of the security extensions to ext/soap > 3. watch axis2 based implementation development > > I am guessing the security stuff could take a bit to implement. Does > anyone feel "responsible" for this item? > > Engine additions > > 2. add a new 64bit integer that is always 64bits regardless of > platform with the cast name for this new type is (int64) and internally > we use IS_INT64 and RETURN_INT64 etc.. > > Are we still on track with this one? > > 4. add an ifsetor() construct with the middle value for the ?: > ternary operator dropped > > Kinda scared to mention this one. Me want very much though :) > > 6. speed up @-operator and ask andi for approval (ilia, marcus) > 7. add ability to allocate persistent zvals in PHP.
This is more like - ask ZE not to clean what it points to when it is cleaning up the zval, and of course not to allow userland to change it. I needed a similar thing in mysqlnd and went the route of implementing it on extension level - doing magic with reference counting. Doing this means that when the user tries to change the internal buffer pointed by the zval she performs copy-on-write. Having ZE support for this will be nice! Andrey

Stanislav Malyshev

19 years ago
> This is more like - ask ZE not to clean what it points to when it is > cleaning up the zval, and of course not to allow userland to change it.
Well, actually persisting zvals between requests would be very problematic since it can not then use regular memory allocator (which is cleaned up at the request end). Which means the engine must know which allocator allocated the variable, otherwise we'd get a lot of trouble when mixing such variables in the same context. Also, it's not clear for me what such variable could be used for. I see only two potential uses: 1. Persistent resources. You don't really need zval then - persist the resource and allocate zval on need. Resources are refcounted separately, so no problem. 2. Caching. Here one would be much better to use external (with regard to the engine) caching solution - persisting zval would not gain that much since it's still limited to the process (which may not be either accessible or alive next time you need it) and overhead of converting regular zval to persistent one would be roughly the same as overhead for serializing zval into some form of cache. So I'd leave this to extensions. Are there any other reasons for persistent zvals?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Andrei Zmievski

19 years ago
Yes, if we have persistent zvals we can use objects/arrays as properties or constants for internal classes. I asked for this 2.5 years ago. -Andrei On Apr 12, 2007, at 3:57 PM, Stanislav Malyshev wrote:

Stanislav Malyshev

19 years ago
> Yes, if we have persistent zvals we can use objects/arrays as properties > or constants for internal classes. I asked for this 2.5 years ago.
If they are initialized on startup, I think it's doable, though they shouldn't be directly accessible to the PHP user, since they should be immutable. So constants are OK, but properties might be a bit of a problem.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Andrei Zmievski

19 years ago
That can be handled with read_property and write_property handlers. Disallowing access to PHP users is an artificial restriction that we should find ways around. -Andrei On Apr 13, 2007, at 12:43 PM, Stanislav Malyshev wrote:

Stanislav Malyshev

19 years ago
> That can be handled with read_property and write_property handlers. > Disallowing access to PHP users is an artificial restriction that we > should find ways around.
If you have these handlers, why you need read-made persistent zvals? You can construct any zval you want once property is read and you can do anything you want once property is written, what persistent zval would give you then?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Andrei Zmievski

19 years ago
Fine, let's step back for a bit. What I want to be able to do is have objects/arrays as internal properties and constants. Can we make that possible? Last time I looked it required having persistent zvals. -Andrei On Apr 13, 2007, at 1:03 PM, Stanislav Malyshev wrote:

Stanislav Malyshev

19 years ago
> Fine, let's step back for a bit. What I want to be able to do is have > objects/arrays as internal properties and constants. Can we make that > possible? Last time I looked it required having persistent zvals.
I think to better understand what would be required a use case would help a lot. Could you bring forward 1-2 scenarios how one would use it?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Michael Wallner

19 years ago
Stanislav Malyshev wrote:
>> Fine, let's step back for a bit. What I want to be able to do is have >> objects/arrays as internal properties and constants. Can we make that >> possible? Last time I looked it required having persistent zvals. > > I think to better understand what would be required a use case would > help a lot. Could you bring forward 1-2 scenarios how one would use it?
Initializing a static class resp. default instance variable with f.e. an array is an obvious use case. Regards,
-- Michael

Antony Dovgal

19 years ago
On 04/12/2007 06:37 PM, Lukas Kahwe Smith wrote:
> 3. remove old parameter parsing API and replace with one that > supports unicode related functionality > > I just want to remind that when we made some changes to the parameter > parsing API's last time it created some BC issues (like with > array_merge() ..)
Yes, that's why we need much more tests.
> 5. add unicode to pdo (wez) > > Maybe one place where IBM could step up, seeing that they are putting a > lot of resources into their PDO drivers.
As long as it doesn't involve signing a legal paper to submit a patch, I'm all for it.
> 4. safe_mode/open_basedir > 1. remove safe mode and throw E_CORE_ERROR when set > 2. unbundle safe_mode_exec_dir from safe_mode and keep it > (rasmus) (take a look at this patch too)
safe_mode_exec_dir without a safe mode? Makes little sense to me.
> 3. new ini option: open_basedir_for_include which would allow > using include/require(_once) on an expanded set of directories (sara)
I'm -1 on this.
> 9. remove zend.ze1_compatibility mode and throw E_CORE_ERROR when > set DONE (dmitry)
Yes, gone in HEAD.
> 3. regexp > 1. make ereg an extension > 2. PCRE extension will not be allowed to be disabled. > 3. core of PHP should be made to work with PCRE so that we can > safely disable ereg > 4. unbundle the regex library > > We had a short discussion on this one not too long ago.
I can take a look at this (I'm 100% sure nobody is actually interested in new regex extension as long as we have pcre). Do you have any links on the discussion or do you recall what was the decision?
> 5. move mime_magic from the core to PECL > 6. fileinfo > 1. move the Fileinfo extension to the core, and enable it by > default. > 2. Fileinfo extension should be updated to only load its > database once on MINIT.
I already mentioned I'm strongly against moving any extensions from PECL to core. It should be the other way round.
> 7. ext/soap > 1. ext/soap will be turned on by default > 2. implement some of the security extensions to ext/soap > 3. watch axis2 based implementation development > > I am guessing the security stuff could take a bit to implement. Does > anyone feel "responsible" for this item?
IIRC Rob was working on some XMLSec stuff, no idea what's its status though..
> 4. add an ifsetor() construct with the middle value for the ?: > ternary operator dropped > > Kinda scared to mention this one. Me want very much though :)
Marcus added recently something like this.
> 5. fix __toString() DONE (marcus) > > Didn't we fix this one in 5.x already?
Yeah, fixed since 5.2.0.
> 5. split allow_url_fopen into two distinct settings: allow_url_fopen > and allow_url_include. If allow_url_fopen is off, then allow_url_include > will be off too. > 6. enable allow_url_fopen by default > 7. disable allow_url_include by default > > Is this still going to happen?
Already done (in 5.2.0 IIRC).
> 11. kill "<%" but keep "<?". > > Sounds easy enough to do. Why not do it know, so that we can hear about > the impact for users as early as possible.
Yeah, I'll post the patch in a minute..
> 12. prepare a patch that disallows mixing different open/close tags. > (jani) > > Jani .. looks like you are back!? :)
Yay! =)
-- Wbr, Antony Dovgal

Edin Kadribasic

19 years ago
Antony Dovgal wrote:
>> 11. kill "<%" but keep "<?". >> >> Sounds easy enough to do. Why not do it know, so that we can hear >> about the impact for users as early as possible. > > Yeah, I'll post the patch in a minute..
Please leave this alone. There is no advantage to removing it and it breaks existing apps. We have also discussed this and decided against it after it was posted as one of the suggestions from the Paris meeting. No need to go over the same argument again. Edin

Antony Dovgal

19 years ago
On 04/12/2007 11:38 PM, Edin Kadribasic wrote:
> Antony Dovgal wrote: >>> 11. kill "<%" but keep "<?". >>> >>> Sounds easy enough to do. Why not do it know, so that we can hear >>> about the impact for users as early as possible. >> >> Yeah, I'll post the patch in a minute.. > > Please leave this alone. There is no advantage to removing it
Surely there is, we're removing one more useless feature.
> and it breaks existing apps.
I've never seen such apps and I doubt they even exist. And they do, this is PHP3 legacy stuff which won't work in PHP6 anyway.
> We have also discussed this and decided against it > after it was posted as one of the suggestions from the Paris meeting. > > No need to go over the same argument again.
-- Wbr, Antony Dovgal

Rob Richards

19 years ago
Antony Dovgal wrote:
> On 04/12/2007 06:37 PM, Lukas Kahwe Smith wrote: >> 7. ext/soap >> 1. ext/soap will be turned on by default >> 2. implement some of the security extensions to ext/soap >> 3. watch axis2 based implementation development >> >> I am guessing the security stuff could take a bit to implement. Does >> anyone feel "responsible" for this item? > > IIRC Rob was working on some XMLSec stuff, no idea what's its status > though.. >
An XMLSec extension is close to an alpha release. There are a few of us actually working on it, Alexandre Kalendarev is doing the bulk of the work right now, and we're almost there. It's based on the xmlsec library and we decided to add WS-Security functionality directly into that library and just leverage that functionality, so we keep getting delayed fixing problems we're creating within xmlsec itself while trying to maintain BC while adding the functionality we need to hook into it properly. As far as implementing these into soap, I still think having these as external extensions that can be accessed from ext/soap rather than baking directly into ext/soap is best option and would mean just adding some additional plugin-in points during the message processing. The PHP code I wrote for WS-Security (which really amounts to only a small portion of that actualy specs) seems to satisfy at least 90% of the people looking to implement some of the basic WS-* stack with PHP. The functionality we are looking to add to an XMLSec extension would not only help speed up the processing but also expand the amount of supported algorithms, transformations, etc.. detailed in the specs. Projects needing to support more complex situations would probably would want a much larger SOAP framework (like .NET, WCF, XFire, etc.. - personally I like .NET/WCF here). As far as axis2 (WSF for PHP), I have been playing around with it for quite some time now. It still has a lot of bugs to be worked out but does seem to be aiming to compete with the larger SOAP frameworks. This, however, is one of the reasons I really don't think it should replace the existing soap extension. The current source for WSF for PHP is almost 6MB in size and its not as simple to use as ext/soap. It would add a lot of bloat and confusion when in most cases creating simple SOAP clients is the desired functionality. Basically I think it might make a good alternative for someone to use as a more complex SOAP framework, but not one to be included in PHP core. Rob

LAUPRETRE François (P)

19 years ago
> From: Antony Dovgal [mailto:antony@zend.com] > > > 3. regexp > > 1. make ereg an extension > > 2. PCRE extension will not be allowed to be disabled. > > 3. core of PHP should be made to work with PCRE so that we can > > safely disable ereg > > 4. unbundle the regex library > > > > We had a short discussion on this one not too long ago. > > I can take a look at this (I'm 100% sure nobody is actually > interested in new regex extension as long as we have pcre). > Do you have any links on the discussion or do you recall what > was the decision?
IIRC, we agreed on 1, 2, 3, but not to move ereg to PECL. Ereg was to remain in core as an optional extension (disabled by default). François

Derick Rethans

19 years ago
On Thu, 12 Apr 2007, Lukas Kahwe Smith wrote:
> 5. move mime_magic from the core to PECL > 6. fileinfo > 1. move the Fileinfo extension to the core, and enable it by default. > 2. Fileinfo extension should be updated to only load its database > once on MINIT. > > Didn't we fast track these two to 5.x?
Nope, as we'd need to put the database into a .h/.c file so that we don't have to rely on something external. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Kahwe Smith

19 years ago
Hi, FYI I have updated the todo list according to the recent discussions: http://oss.backendmedia.com/index.php?area=PHPTODO&page=PhP60&view=diff&to=2007-04-17+10%3A47%3A32&from=2007-04-12+16%3A32%3A02 regards, Lukas

Lukas Kahwe Smith

19 years ago
Hey, I have a few more questions: Other Additions/Changes: 7. add E_STRICT to E_ALL DONE (dmitry) Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED in PHP 5.3. Once we do that I think this change should be adjusted to only include E_DEPRECATED in E_ALL and not E_STRICT. Or whats the POV here? regards, Lukas

Hannes Magnusson

19 years ago
On 4/17/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
> Hey, > > I have a few more questions: > > Other Additions/Changes: > > 7. add E_STRICT to E_ALL DONE (dmitry) > > Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED > in PHP 5.3. Once we do that I think this change should be adjusted to > only include E_DEPRECATED in E_ALL and not E_STRICT. Or whats the POV here?
My dictionary says that "all" means *all*, not "all except this and this and sometimes not that". -Hannes

Christian Schneider

19 years ago
Hannes Magnusson wrote:
>> 7. add E_STRICT to E_ALL DONE (dmitry) > > My dictionary says that "all" means *all*, not "all except this and > this and sometimes not that".
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this confusion but in reality changing E_ALL to include everything would unnecessarily break existing installations. I think we will have to live with this misnomer and not try to 'fix' it. I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not even sure if E_DEPRECATED should be included in E_ALL: It depends on how liberally things will get marked E_DEPRECATED. - Chris

Hannes Magnusson

19 years ago
On 4/17/07, Christian Schneider <cschneid@cschneid.com> wrote:
> Hannes Magnusson wrote: > >> 7. add E_STRICT to E_ALL DONE (dmitry) > > > > My dictionary says that "all" means *all*, not "all except this and > > this and sometimes not that". > > E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this > confusion but in reality changing E_ALL to include everything would > unnecessarily break existing installations. I think we will have to live > with this misnomer and not try to 'fix' it.
How exactly would any app break? You don't display errors on your production server, do you? It will only help you understand what is going on while you develop the application. I think what we need here is fix our php.ini files: php.ini-production & php.ini-developing -Hannes

Richard Quadling

19 years ago
On 17/04/07, Hannes Magnusson <hannes.magnusson@gmail.com> wrote:
> On 4/17/07, Christian Schneider <cschneid@cschneid.com> wrote: > > Hannes Magnusson wrote: > > >> 7. add E_STRICT to E_ALL DONE (dmitry) > > > > > > My dictionary says that "all" means *all*, not "all except this and > > > this and sometimes not that". > > > > E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this > > confusion but in reality changing E_ALL to include everything would > > unnecessarily break existing installations. I think we will have to live > > with this misnomer and not try to 'fix' it. > > How exactly would any app break? > You don't display errors on your production server, do you? > It will only help you understand what is going on while you develop > the application. > > I think what we need here is fix our php.ini files: php.ini-production > & php.ini-developing > > -Hannes
In development mode I want to see every single error/notice/warning/etc. How else am I supposed to know if I've done something incorrect or the sand has shifted beneath my feet and I didn't realise? In production no errors should be displayed (i.e. all nice clean code) but even if they are they should only be logged and not displayed. So in both circumstances E_ALL should __still__ mean every single error/notice/warning/etc. I do like the idea of production and development ini files. That seems to make more sense than recommended and dist. I'm sure dist means distribution, but then what does recommended mean? Without knowing the reason, seeing recommended and dist are confusing.
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Richard Lynch

19 years ago
On Tue, April 17, 2007 8:15 am, Hannes Magnusson wrote:
> On 4/17/07, Christian Schneider <cschneid@cschneid.com> wrote: >> Hannes Magnusson wrote: >> >> 7. add E_STRICT to E_ALL DONE (dmitry) >> > >> > My dictionary says that "all" means *all*, not "all except this >> and >> > this and sometimes not that". >> >> E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid >> this >> confusion but in reality changing E_ALL to include everything would >> unnecessarily break existing installations. I think we will have to >> live >> with this misnomer and not try to 'fix' it. > > How exactly would any app break? > You don't display errors on your production server, do you?
*I* don't, but some users do. If you can get them all to fix that first, we're all set... :-v
> It will only help you understand what is going on while you develop > the application. > > I think what we need here is fix our php.ini files: php.ini-production > & php.ini-developing
That would help quite a bit.
-- 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?

Lukas Kahwe Smith

19 years ago
Christian Schneider wrote:
> I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not
Feel like working up a patch for 5.3 for this? :) regards, Lukas

Lukas Kahwe Smith

19 years ago
Hey, What is the status regarding reflection and spl. Do we still want to allow disabling? regards, Lukas

Pierre Joye

19 years ago
On 4/17/07, Lukas Kahwe Smith <smith@pooteeweet.org> wrote:
> Hey, > > What is the status regarding reflection and spl. Do we still want to > allow disabling?
Most of its features could (should?) be moved to ZE2 as they are what can be considered as part of the language. It is even more important as some them are required to work around recent changes/fixes in ZE2 (for example __set/__get used with arrays can be done with ArrayObject). As any other language features, it will not be possible to disable them. Doing so will not only help our users but ease the extensions development. That being said, I never really understood why it was developed outside ZendEngine2 (at least for the main classes like ArrayObject, ArrayIterator, iterator_to_array or class_* (these two are the most obvious candidate!) . --Pierre