[PHP-DEV] RE : [PHP-DEV] PHP6 todo list
From: Antony Dovgal [mailto:[EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Yes, PHP-GTK. :) I don't know much of the GTK, let alone PHP-GTK. What PHP-GTK stores in static arrays? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Yes, PHP-GTK. :)
-Andrei
On Apr 16, 2007, at 11:36 AM, Stanislav Malyshev wrote:
Sorry for the cryptic reply. I think that initializing a static
class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an
extension:
class c {
static $prop1 = array(foo, bar);
var $prop2 = array(1,2,3);
}
I see, thanks. Are there any existing internal classes that need
this capability?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Hi, FYI I have updated the todo list according to the recent discussions: http://oss.backendmedia.com/index.php?area=PHPTODOpage=PhP60view=diffto=2007-04-17+10%3A47%3A32from=2007-04-12+16%3A32%3A02 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (spl/reflection disabling allowed?)
Hey, What is the status regarding reflection and spl. Do we still want to allow disabling? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
On 4/17/07, Lukas Kahwe Smith [EMAIL PROTECTED] 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 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
On 4/17/07, Christian Schneider [EMAIL PROTECTED] 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
On 17/04/07, Hannes Magnusson [EMAIL PROTECTED] wrote: On 4/17/07, Christian Schneider [EMAIL PROTECTED] 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=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (spl/reflection disabling allowed?)
On 4/17/07, Lukas Kahwe Smith [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list (E_STRICT in E_ALL)
On Tue, April 17, 2007 8:15 am, Hannes Magnusson wrote: On 4/17/07, Christian Schneider [EMAIL PROTECTED] 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Stanislav Malyshev wrote:
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.
Err, I'm afraid I don't understand neither your abbreviations nor what
the actual use case is. Can you describe real use case - i.e. module X
has functionality A and B, and to make A work with B I would use
persistent zvals so that when Foo is called Bar happens.
Sorry for the cryptic reply. I think that initializing a static class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an extension:
class c {
static $prop1 = array(foo, bar);
var $prop2 = array(1,2,3);
}
Regards,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Sorry for the cryptic reply. I think that initializing a static class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an extension:
class c {
static $prop1 = array(foo, bar);
var $prop2 = array(1,2,3);
}
I see, thanks. Are there any existing internal classes that need this
capability?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Initializing a static class resp. default instance variable with f.e. an array is an obvious use case. Err, I'm afraid I don't understand neither your abbreviations nor what the actual use case is. Can you describe real use case - i.e. module X has functionality A and B, and to make A work with B I would use persistent zvals so that when Foo is called Bar happens. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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: 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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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: 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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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: 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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP6 todo list
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
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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/[EMAIL PROTECTED]/msg22098.html Would be the discussion if it still matters then :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php6 todo list ..
Hi, I just wanted to ask everybody working on PHP6 to take the time to look over the PHP6 todo list [1] and note any items that need to be updated. As always either let me know if you need a login or simply send me what you think needs changed. I am sure that a few items can probably be marked done, others have become obsolete and yet others need to be added. One thing to maybe also look at are the comments at the bottom. People have been abusing them to add feature requests. I can clean them up after someone has ensured that no sensible request is lost. This will make it a lot easier to plan releases once we are ready to do so and so I am sure whoever becomes RM for PHP6 will much appreciate an uptodate todo list. As always, I am very willing to invest time if people point me in the right directions in order to keep the work load as low as possible for core contributors. regards, Lukas PS: Ilia, let me know if you require any effort on the PHP 5.2.x todo list. [1] http://oss.backendmedia.com/PhP60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
