Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 10:41 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure we do not forget something. regards, Lukas Kahwe Smith [EMAIL PROTECTED] PS: I know this might sound like an invitation for a flame war, it isnt. Please keep replies as technical as possible. Thanks! 1) We have broken streams, currently: http://bugs.php.net/bug.php?id=46049 2) We still need someone to do upgrades to new parameter-parsing api in a) ext/mysql and ext/mysqli (I believe these are in works and will be committed soon) b) ext/interbase (any volunteers?) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Lukas Kahwe Smith wrote: On 10.11.2008, at 11:41, Jani Taskinen wrote: 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) IIRC we are not yet in agreement on the removal. AFAIK its already an extension in PHP6, but I am not sure if we wanted to continue with the You don't follow the CVS a lot, do you? revision 1.2.2.2 date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0 MFH:- Moved the old regex functions to own extension: ereg proposal that Andrei (IIRC) made to remove it. If we are doing to remove it we should add E_DEPRECATED. 3. Remove ext/mhash (replaced by ext/hash) So what was the deal here? ext/hash automatically provides the ext/mhash functions if the extension is not compiled in. So the main reason to keep ext/mhash is just to allow if extension mhash exists .. ? I think this is easy enough for people to fix by replacing this check with an function_exists() check. Exactly. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, 2008-11-10 at 12:41 +0200, Jani Taskinen wrote: 1. Change ext/phar to be disabled by default Is that the only case? We have a few new extensions, fileinfo is enabled by default at the moment, hash is, sqlite3 is, ... So the question is: What's the purpose of bundling extensions and what's the risk? - In general I think the reason to bundle stuff is to make it available as default stuff, so enabling by default makes sense. But then we also have to enable more stuff without external dependencies (mbstring, mysqlnd [1]) and we should consider enabling by default stuff where header and libs are on most systems (like zlib) ... but then again we get a really big beast as default config. So, what's the right line? 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) kind of related to the previous thing, we should at least deprecate it, removing has benefits as it's often insecure to use ereg (barely anyone is aware of \0-Byte problems ...) 3. Remove ext/mhash (replaced by ext/hash) isn't mhash just a compatibility wrapper on top of hash? Kicking that out is bad for getting people to migrate to 5.3. johannes [1] Disclaimer: I'm paid by Sun/MySQL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Lester Caine wrote: Lukas Kahwe Smith wrote: Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in the 5.3.x snapshot - I don't have time to go through every one to check their status. Is that information available somewhere? This is why I asked to check the NEWS file: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=logpathrev=PHP_5_3 That file should list all intentional changes. If something is changed which is not listed there, it either needs to be listed or fixed. OK - one of the missing things here is the windows builds of the pecl code. This used to be provided as a separate zip in the old snapshot system, and so it made little difference if a package was core or pecl. Is there a current windows snapshot of the pecl library, and a matching PECL-5.3.0 to go with the alpha builds anywhere? ( A couple of the packages I'm missing are in the pecl pack on 5.2.x which is why there was a little confusion on what was available ) OK going on from this. Current windows alpha does not have php_dba.dll php_gmp.dll php_mcrypt.dll php_pspell.dll php_snmp.dll And I presume php_zip.dll has moved to pecl as it's now available there, but none of them are appearing in the notes. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] alpha3 or forever hold your peace
-Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: 10 November 2008 08:23 To: PHP internals Subject: Re: [PHP-DEV] alpha3 or forever hold your peace Lukas Kahwe Smith wrote: I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure we do not forget something. There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. APC is another missing extension. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? Regards Jaroslav Hanslik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]: Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Kalle Sommer Nielsen wrote: 2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]: Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. If the enchant PECL extension works then it wraps around pspell or whatever other spelling libraries that are available. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote: 2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]: Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. Enchant works but not using pspell (for the same reason than ext/pspell does not), it works with almost any other spelling system, on all platforms. But that's not the problem neither the solution as enchant is not part of the core. pspell and netsmnp libraries are not portable and can't be built on windows. We don't feel like releasing packages with critical security issues is a good thing to do. If we do not find a solution by the time of 5.3-final, we can always provide an extra package with these packages but with a (very) strong warning about using them in production environment. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On 10.11.2008, at 16:06, Pierre Joye wrote: On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote: 2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]: Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. Enchant works but not using pspell (for the same reason than ext/pspell does not), it works with almost any other spelling system, on all platforms. But that's not the problem neither the solution as enchant is not part of the core. Should we examine if we want to make enchant part of core? I guess you are one of the maintainers, so the prime candidate to tell us if you think its ready .. pspell and netsmnp libraries are not portable and can't be built on windows. We don't feel like releasing packages with critical security issues is a good thing to do. If we do not find a solution by the time of 5.3-final, we can always provide an extra package with these packages but with a (very) strong warning about using them in production environment. I agree. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On 10.11.2008, at 12:27, Jani Taskinen wrote: 4. Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641edit=1 If there is a significant show of hands of people that feel that the code in HEAD is so much easier to maintain, that suddenly they feel more inclined than before to actually care about bugs in output buffering and that they will take care of any BC issues that pop up, Johannes and I might reconsider our decision to not MFH OB. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On 10.11.2008, at 12:04, Jani Taskinen wrote: Lukas Kahwe Smith wrote: On 10.11.2008, at 11:41, Jani Taskinen wrote: 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) IIRC we are not yet in agreement on the removal. AFAIK its already an extension in PHP6, but I am not sure if we wanted to continue with the You don't follow the CVS a lot, do you? I do, but sometimes I miss a commit. revision 1.2.2.2 date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0 MFH:- Moved the old regex functions to own extension: ereg Ok, so its already an extension in PHP 5.3, that does not mean that we have scheduled its removal in PHP 6. Personally I am fine with removing ereg, but then again I have always refrained from using ereg. Its going to be a bit of a pain, but IIRC ereg is not going to play well in our brave new unicode world unless someone does considerable work on ereg .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Marcus Boerger wrote: Hello Jani, Monday, November 10, 2008, 11:41:44 AM, you wrote: Lukas Kahwe Smith wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default We are not disabling thois because Jani doesn't like it. Eh? It wasn't supposed to be enabled everywhere from the beginning! Only for the RC stage. Search the mailing list. It's not about me not liking it or not, it's about general usefulness. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Johannes Schlüter wrote:
On Mon, 2008-11-10 at 12:41 +0200, Jani Taskinen wrote:
1. Change ext/phar to be disabled by default
Is that the only case? We have a few new extensions, fileinfo is enabled
by default at the moment, hash is, sqlite3 is, ...
So the question is: What's the purpose of bundling extensions and what's
the risk? - In general I think the reason to bundle stuff is to make it
available as default stuff, so enabling by default makes sense. But
then we also have to enable more stuff without external dependencies
(mbstring, mysqlnd [1]) and we should consider enabling by default stuff
where header and libs are on most systems (like zlib) ... but then again
we get a really big beast as default config.
So, what's the right line?
I'm fine with adding more things to the default, we all know that any
distro is going to ignore what we recommend and separate it into packages.
2. Change ext/ereg to be disabled by default (scheduled to be removed in
PHP 6, iirc?)
kind of related to the previous thing, we should at least deprecate it,
removing has benefits as it's often insecure to use ereg (barely anyone
is aware of \0-Byte problems ...)
3. Remove ext/mhash (replaced by ext/hash)
isn't mhash just a compatibility wrapper on top of hash? Kicking that
out is bad for getting people to migrate to 5.3.
The compatability stuff is in ext/hash the code in ext/mhash is purely
there for extension_loaded('mhash') though I would expect more people to
use function_exists()
Looking at google codesearch shows that its going to affect pear Crypt
and squirrelmail. I'm however fine with removing it.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Jani Taskinen wrote: Lukas Kahwe Smith wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) 3. Remove ext/mhash (replaced by ext/hash) I forgot this one: 4. Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641edit=1 --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. You know why ibase is missing (see the firebird-php archive as well). And I would like to know which other dozen of extensions are missing. Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but my main testbed is the windows stuff. This sentence makes no sense. And we already explained hundred of times what was used in 5.2 is not usable anymore (security, reliability, can't be updated, no src, etc.). Please check the archives if you need a detailed explanation. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Pierre Joye wrote: On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. You know why ibase is missing (see the firebird-php archive as well). And I would like to know which other dozen of extensions are missing. Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in the 5.3.x snapshot - I don't have time to go through every one to check their status. Is that information available somewhere? Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but my main testbed is the windows stuff. This sentence makes no sense. And we already explained hundred of times what was used in 5.2 is not usable anymore (security, reliability, can't be updated, no src, etc.). Please check the archives if you need a detailed explanation. This only seems to be a problem with windows builds? Although the other branch of this thread has brought up something that I simply was not aware of. It may well have been thoroughly discussed and documented, but if that is the current problem, then we can deal with it - if someone how knows what changes are needed can point us in the right direction ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On 10.11.2008, at 11:42, Lester Caine wrote: Pierre Joye wrote: On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. You know why ibase is missing (see the firebird-php archive as well). And I would like to know which other dozen of extensions are missing. Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in the 5.3.x snapshot - I don't have time to go through every one to check their status. Is that information available somewhere? This is why I asked to check the NEWS file: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=logpathrev=PHP_5_3 That file should list all intentional changes. If something is changed which is not listed there, it either needs to be listed or fixed. Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but my main testbed is the windows stuff. This sentence makes no sense. And we already explained hundred of times what was used in 5.2 is not usable anymore (security, reliability, can't be updated, no src, etc.). Please check the archives if you need a detailed explanation. This only seems to be a problem with windows builds? Although the other branch of this thread has brought up something that I simply was not aware of. It may well have been thoroughly discussed and documented, but if that is the current problem, then we can deal with it - if someone how knows what changes are needed can point us in the right direction ... I just talked to Pierre and he said he is in contact with people from Firebird to get this resolved. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] alpha3 or forever hold your peace
But where? pecl4win.php.net hasn't compiled APC since January, and certainly nothing for 5.3 And can't see anything on windows.php.net containing APC compiled for 5.3 Jared -Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: 10 November 2008 12:32 To: PHP internals Subject: Re: [PHP-DEV] alpha3 or forever hold your peace Jared Williams wrote: APC is another missing extension. apc is in pecl - so would be provided with the PECL binary. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- 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] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 1:21 PM, Lester Caine [EMAIL PROTECTED] wrote: Current windows alpha does not have php_mcrypt.dll mcrypt is present (builtin) php_dba.dll php_gmp.dll They will be in the next release. php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). And I presume php_zip.dll has moved to pecl as it's now available there, but none of them are appearing in the notes. zip is present too (builtin) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] alpha3 or forever hold your peace
-Original Message- From: Pierre Joye [mailto:[EMAIL PROTECTED] Sent: 10 November 2008 15:46 To: Jared Williams Cc: Lester Caine; PHP internals Subject: Re: [PHP-DEV] alpha3 or forever hold your peace On Mon, Nov 10, 2008 at 4:43 PM, Jared Williams [EMAIL PROTECTED] wrote: But where? pecl4win.php.net hasn't compiled APC since January, and certainly nothing for 5.3 pecl4win is dead and will not be restored anymore. In the next weeks, pecl.php.net will provide the DLLs based on releases instead of random snapshots, for each active branches (5.2, 5.3 and HEAD). Cheers, thanks. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 1:18 PM, Lester Caine [EMAIL PROTECTED] wrote: Alexey Zakhlestin wrote: 2) We still need someone to do upgrades to new parameter-parsing api in b) ext/interbase (any volunteers?) Where will I find some help on actually what needs doing? I presume that the Linux build has not been updated although I'm not actually seeing a problem at present. Perhaps I've simply got that wrong as well :( Simple instruction is here: http://marc.info/?l=php-internalsm=121391697512351w=2 -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Pierre Joye wrote: pecl4win is dead and will not be restored anymore. In the next weeks, pecl.php.net will provide the DLLs based on releases instead of random snapshots, for each active branches (5.2, 5.3 and HEAD). Does this mean we will have the same problem with pecl that we currently have with pear when trying to build an installation disk for a secure site ( one with no internet access ), and have to download everything one at a time rather than just downloading a single full package? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 18:06, Lester Caine [EMAIL PROTECTED] wrote: Pierre Joye wrote: pecl4win is dead and will not be restored anymore. In the next weeks, pecl.php.net will provide the DLLs based on releases instead of random snapshots, for each active branches (5.2, 5.3 and HEAD). Does this mean we will have the same problem with pecl that we currently have with pear when trying to build an installation disk for a secure site ( one with no internet access ), and have to download everything one at a time rather than just downloading a single full package? Not if you help implementing this thing no. Otherwise there are no guarantees. Either way, this is not a internals@ subject, please move it to pecl-dev@ -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On 10.11.2008, at 11:41, Jani Taskinen wrote: 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) IIRC we are not yet in agreement on the removal. AFAIK its already an extension in PHP6, but I am not sure if we wanted to continue with the proposal that Andrei (IIRC) made to remove it. If we are doing to remove it we should add E_DEPRECATED. 3. Remove ext/mhash (replaced by ext/hash) So what was the deal here? ext/hash automatically provides the ext/ mhash functions if the extension is not compiled in. So the main reason to keep ext/mhash is just to allow if extension mhash exists .. ? I think this is easy enough for people to fix by replacing this check with an function_exists() check. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 4:43 PM, Jared Williams [EMAIL PROTECTED] wrote: But where? pecl4win.php.net hasn't compiled APC since January, and certainly nothing for 5.3 pecl4win is dead and will not be restored anymore. In the next weeks, pecl.php.net will provide the DLLs based on releases instead of random snapshots, for each active branches (5.2, 5.3 and HEAD). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
On 10.11.2008, at 12:06, Jani Taskinen wrote: Marcus Boerger wrote: Hello Jani, Monday, November 10, 2008, 11:41:44 AM, you wrote: Lukas Kahwe Smith wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/ removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default We are not disabling thois because Jani doesn't like it. Eh? It wasn't supposed to be enabled everywhere from the beginning! Only for the RC stage. Search the mailing list. It's not about me not liking it or not, it's about general usefulness. No, this is just your selective interpretation of the situation. We decided to enable it by default because if we felt its important to be enabled by default. We left ourselves the option of not enabling it by default (or even removing it) in case we find issues that make it unfit to be enabled by default (or bundled). So far it seems that Greg/Marcus/Steph have been quick to react to any issues that have popped up. Checking the pecl and php bug tracker seems to validate this. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Hannes Magnusson wrote: On Mon, Nov 10, 2008 at 18:06, Lester Caine [EMAIL PROTECTED] wrote: Pierre Joye wrote: pecl4win is dead and will not be restored anymore. In the next weeks, pecl.php.net will provide the DLLs based on releases instead of random snapshots, for each active branches (5.2, 5.3 and HEAD). Does this mean we will have the same problem with pecl that we currently have with pear when trying to build an installation disk for a secure site ( one with no internet access ), and have to download everything one at a time rather than just downloading a single full package? Not if you help implementing this thing no. Otherwise there are no guarantees. Either way, this is not a internals@ subject, please move it to pecl-dev@ Not our problem now? In the past we have had builds that we could work with and test - including the pecl library. With even more packages being moved to pecl, then this is even more important, but it looks like PHP5.3alpha3 will be a rather cut down version of what is currently available in PHP5.2.7 - at least on windows? At the current time there is no way to test a windows system that currently runs happily on PHP5.2.X on PHP5.3 because key components provided via pecl or in internals are simply not yet available. Until we can get a version of PHP5.3 that we CAN test ... PHP6 seems to be in the same limbo as well? ( Currently my development Linux box is laying flat on it's back with it's legs in the air because Mandriva2009/KDE4 simply will not play with my hardware - just another 'improvement' that wastes even more time so I can't even try PHP5.3 on Linux at the moment :( ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Lukas Kahwe Smith wrote: I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure we do not forget something. There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but my main testbed is the windows stuff. ( Please - No comments about Not needing xxx to test! - My initial test suit runs everything against the database - no database it fails ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Lukas Kahwe Smith wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) 3. Remove ext/mhash (replaced by ext/hash) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Alexey Zakhlestin wrote: 2) We still need someone to do upgrades to new parameter-parsing api in b) ext/interbase (any volunteers?) Where will I find some help on actually what needs doing? I presume that the Linux build has not been updated although I'm not actually seeing a problem at present. Perhaps I've simply got that wrong as well :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Fri, 2008-11-07 at 09:57 +0100, Pierre Joye wrote: It is why alpha releases are for. If we don't merge it we should simply drop it in HEAD and forget it. This code has been there for years now, it is time to bring it to a stable branch. The same applies for other code in HEAD not having merged to 5.3. So, did anybody do a review of the ob code? I know it's in HEAD for ages, but I consider the ob stuff a critical part of PHP which I don't want to see broken, I'm fine with some random extension being broken, but not with a central piece of PHP .. and even having it in HEAD doesn't mean it's really tested there - I guess just a few people do more with head than just compiling and running make test. Back one year ago, it was discussed and I liked it but nobody had the timemotivation to port it to 5.3, having it early would have been nice. For now: Who does a review and who is willing to be responsible for fixing probable bugs? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Hello Jani, Monday, November 10, 2008, 11:41:44 AM, you wrote: Lukas Kahwe Smith wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default We are not disabling thois because Jani doesn't like it. 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) Do we already have plans on how and when to move this to pecl? 3. Remove ext/mhash (replaced by ext/hash) Yep, should be dropped. --Jani Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Please bring up any areas you are concerned about that we might have forgotten. PHP_5_3 as of this morning does not contain that patch that makes ArrayObject behave like an array (reset()). Here's a test for that (I don't have php-src karma) if anyone would care to commit it. Passes on 5.2.6, but fails on 5.3alpha3-dev S --TEST-- Ensure that ArrayObject acts like an array --SKIPIF-- --FILE-- ?php $a = new ArrayObject; $a['foo'] = 'bar'; echo reset($a); echo count($a); echo current($a); ? --EXPECT-- bar1bar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Lukas Kahwe Smith wrote: Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in the 5.3.x snapshot - I don't have time to go through every one to check their status. Is that information available somewhere? This is why I asked to check the NEWS file: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=logpathrev=PHP_5_3 That file should list all intentional changes. If something is changed which is not listed there, it either needs to be listed or fixed. OK - one of the missing things here is the windows builds of the pecl code. This used to be provided as a separate zip in the old snapshot system, and so it made little difference if a package was core or pecl. Is there a current windows snapshot of the pecl library, and a matching PECL-5.3.0 to go with the alpha builds anywhere? ( A couple of the packages I'm missing are in the pecl pack on 5.2.x which is why there was a little confusion on what was available ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Pierre Joye napsal(a): On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote: 2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]: Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. Enchant works but not using pspell (for the same reason than ext/pspell does not), it works with almost any other spelling system, on all platforms. But that's not the problem neither the solution as enchant is not part of the core. Could I download exchant extension for Windows anywhere? pspell and netsmnp libraries are not portable and can't be built on windows. We don't feel like releasing packages with critical security issues is a good thing to do. If we do not find a solution by the time of 5.3-final, we can always provide an extra package with these packages but with a (very) strong warning about using them in production environment. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org Regards, Jaroslav Hanslík -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3 or forever hold your peace
Here's a test for that (I don't have php-src karma) if anyone would care to commit it. Passes on 5.2.6, but fails on 5.3alpha3-dev FWIW, I committed that patch today. I'd like for it to pass by RC1 (-: S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
hi! On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? I hope not, it is a must have. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On 07.11.2008, at 09:30, Pierre Joye wrote: hi! On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? I hope not, it is a must have. To quote myself on this topic: These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
hi, On Fri, Nov 7, 2008 at 9:51 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: To quote myself on this topic: These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. It is why alpha releases are for. If we don't merge it we should simply drop it in HEAD and forget it. This code has been there for years now, it is time to bring it to a stable branch. The same applies for other code in HEAD not having merged to 5.3. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
2008/9/29 jvlad [EMAIL PROTECTED]
So as prevoius speaker suggested, and I personaly got to conclusion
in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
Will _you_ write such code? No. Will anybody from this list write such
code?
You may want to write
$a = $b?A:B:C
and how would php compiler resolve A:B:C?
A:B vs C
or A vs B:C?
To me it's better to stay with ::
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
We have (), so just do
$a = $b ? (A:B:C:D) : blah();
Document, that namespaced calls should be in () with ternary operator and
make it a parse error if coder forgets it. That's a good compromise and
little to pay for namespaces, and doesn't break any BC.
I think using ternary operator in such cases isn't realy wise - if () { }
else {} is far more appropriate (anyway, I'l beat my coders for such usage
of ternary operator). So as other members of this thread mentioned - would
you really write code like this:
$a = $b?A:B:C:D;
Are you?
Me 100% not.
Re: [PHP-DEV] alpha3
In response to Larry Garfield's comment that [t]here's nothing familiar about :: to 99.99% of PHP developers who haven't already been playing with the alphas I'd like to point out that since PHP 5.1, the double colon is effectively used as a namespace operator by extensions, in the sense that extensions started using class constants instead of prefixed, global constants. e.g. PDO::PARAM_BOOL instead of PDO_PARAM_BOOL. Usage of class constants (or static methods, for that matter) as a way to preserve the global namespace can also be seen in various projects written in PHP. Additionnally, I'd say there's some familiarity in considering that classes, functions and constants are static members of a namespace the same way that methods and constants can be static members of a class but that may be subject to interpretation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3 branch,
this is going to happen sooner or later. I found that :: just causes to many
questions when used in namespaces. Using :: or - just for the sake of
reusing existing tokens is just wrong. I'm in favor of # if it can be worked
out.
+1 as well, but I must say # is not right, it is a very black/filled
character, as in it doesn't visually#separate#words#that#well. Using
the dot would be really nice, but I guess it would break with
something like this : concat.foo.bar().baz so it's not an option.
Using a single colon might work out ? foo:bar:class::staticFunc()
sounds good to me, but maybe I missed something.
I also had the idea of using the underscore, even though I guess we
can't go through with this as people _might_ have used double
underscores in their class names, I guess it would work out quite well
with single underscores, for example :
class Foo_Bar {
public static function callMe()
}
Foo_Bar::callMe();
..would be read as class Bar in namespace Foo, but it would be
transparent to everyone since if you use something with a fully
qualified name you don't need to use them, right ?
Anyway it's just a couple ideas, but please stop holding on to that
double colon.
--
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi, Ok before we all go crazy with the NS separator debate, some reading (which also links to a few interesting posts/sites): http://marc.info/?l=php-internalsm=113313170231815w=2 http://marc.info/?l=php-internalsm=113345477123705w=2 http://marc.info/?l=php-internalsm=117742643931293w=2 I have also emailed Jessie to see if we can somehow resurrect the content on http://www.phpnamespaces.org/ I invite anyone that seriously wants to have that debate again to scavenge through all of that, write a page on the wiki first. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
2008/9/29 Jordi Boggiano [EMAIL PROTECTED]
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch,
this is going to happen sooner or later. I found that :: just causes to
many
questions when used in namespaces. Using :: or - just for the sake of
reusing existing tokens is just wrong. I'm in favor of # if it can be
worked
out.
+1 as well, but I must say # is not right, it is a very black/filled
character, as in it doesn't visually#separate#words#that#well. Using
the dot would be really nice, but I guess it would break with
something like this : concat.foo.bar().baz so it's not an option.
Using a single colon might work out ? foo:bar:class::staticFunc()
sounds good to me, but maybe I missed something.
I also had the idea of using the underscore, even though I guess we
can't go through with this as people _might_ have used double
underscores in their class names, I guess it would work out quite well
with single underscores, for example :
class Foo_Bar {
public static function callMe()
}
Foo_Bar::callMe();
..would be read as class Bar in namespace Foo, but it would be
transparent to everyone since if you use something with a fully
qualified name you don't need to use them, right ?
Anyway it's just a couple ideas, but please stop holding on to that
double colon.
--
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I agree with you totally that :: makes too much trouble - people are trying
to fix all issues for a few month's now and every time it results in we cut
$something then it works! and of course developers as myself start to shout
that we don't need namespaces half implemented, because they are useless
when.
I took part in discussion in two threads by this time:
here: solving the namespace conflict issues between function/static method
class constant/ns constant
AND
here: true namespaces, yet another point of view
Firstly I also proposed . as a separator, but it has issues with constants:
?php
define('CONST', 'hello ');
class Test {
static function print() {
return 'world!';
}
}
echo CONST.Test::print();
?
That now results in hello world!. So if CONST is a namespace and we have
constant named the same - a problem occures. Well, that can be worked around
- we can check for name collision and give an error, but I think people will
shout at that as bad, wy we can't have namespace and constant named equaly?
Well, I would live with that perfectly, but something tells me developers
will be against this.
Other problem is resolution.
MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a
namespace itself?
As I understand, during compile time that isn't a problem to resolve whether
it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch
isn't a constant, not namespace. Ups, what error should we give? Undefined
constant or missing namespace? Well, as i think of this - only good solution
is Fatal error, but then any forgottent to be set constant will result in
fatal error. To me that is good - I woun't forget to define any constants!
But as I predict - most will shout that it's too harsh, and they will be
right at some point (I myself started with a Pascal, so to me an undefined
variable === compile error (Fatal error in PHP terms), so it's natural to me
to have a Fatal at this point).
So -1 on .
So . is more suitable than ::, but also has it's problems - easier o
resolve, but problems.
In thouse threads people presented next options for namespace separators:
1). .. as separator. Well, two symbols, has no side effects, but looks
quite strage: namespace A..B::staticMethod(). I don't think it's a good one,
so -1.
2). Someone proposed \ as separator. A\B::staticMethod() - Looks crazy,
isn't it? And we all know, that \ mostly has special meaning in programming
languages as escape character. -1.
3). # Co. A#B::staticMethod() - no side effects, bot looks dirty. -1
from me.
4). ::: or . If ::: makes sence, than that man, who proposed should
be joking. ::: - no side effects, just little more to type. A candidate.
Neither -1, nor +1.
So as prevoius speaker suggested, and I personaly got to conclusion in other
thread that : is ideal. Short, isn't taken.
?php
D:F:G:B:H use A;
A:B::staticMethod();
A:B-test();
:phpversion();
?
Looks great, clearly seen and distinguished from :: .
So maybe it is time to stop arguing and maybe use :? Because it finaly comes
out as good choise in many threads.
Please, think about us - developers! We don't want complicated resoution
rules. We don't want half functional namespaces with only classes or without
constants, ect. And : is something is natural, because we allready have ::
separator for static methods. Easy to understand, handy to use, everybody is
happy. Don't you want that?
+1 for
Re: [PHP-DEV] alpha3
I thought that : was rejected because of the terniary operator? I'm not
going to search now for the discussion but for sure there were serious
objections against : , otherwise it would be natural to use it. How you
propose to handle the ambiguities like:
?
print name1:name2?name3:name4:name5:name6;
/*
could mean:
$something?(namespace:namespace:constant) : (constant);
$something?(namespace:constant) : (namespace:constant);
and so on...
*/
?
Parenthesis are a solution, but I have no knoledge of the internal parsing
hence I dont know is it possible.
AFAIK the actual problem with the current implementation with :: is that is
ambigous like:
?
name1::name2();
/*
which could mean:
class::staticcall();
namespace::function();
and so on..
*/
?
My proposal is (if possible/reasonable/performance wise of course) to have a
fatal error thrown when during the parse time the engine discovers
duplicates like the one described above. What is the point to name in the
same way a class and a static method and a namespace and a function in the
same way? In my (very humble) opinion this is the best solution, because we
keep the :: operator that we are familiar with, the ambiguity is resolved
(just not allowing it) and (I guess) the php 5.3 will not be delayed much.
Is there any other logical problem with the namespaces besides this
ambiguity? Have I missed something else?
In fact I'm using a lot the namespaces in their current implementation and
I'm very happy with it. I Never had problems with the ambiguity, because I
never even needed to use duplicated names for the different objects
(classes, constants, static methods, functions).
Vesselin Kenashkov
On Mon, Sep 29, 2008 at 7:05 PM, Arvids Godjuks [EMAIL PROTECTED]wrote:
2008/9/29 Jordi Boggiano [EMAIL PROTECTED]
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED]
wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch,
this is going to happen sooner or later. I found that :: just causes to
many
questions when used in namespaces. Using :: or - just for the sake of
reusing existing tokens is just wrong. I'm in favor of # if it can be
worked
out.
+1 as well, but I must say # is not right, it is a very black/filled
character, as in it doesn't visually#separate#words#that#well. Using
the dot would be really nice, but I guess it would break with
something like this : concat.foo.bar().baz so it's not an option.
Using a single colon might work out ? foo:bar:class::staticFunc()
sounds good to me, but maybe I missed something.
I also had the idea of using the underscore, even though I guess we
can't go through with this as people _might_ have used double
underscores in their class names, I guess it would work out quite well
with single underscores, for example :
class Foo_Bar {
public static function callMe()
}
Foo_Bar::callMe();
..would be read as class Bar in namespace Foo, but it would be
transparent to everyone since if you use something with a fully
qualified name you don't need to use them, right ?
Anyway it's just a couple ideas, but please stop holding on to that
double colon.
--
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I agree with you totally that :: makes too much trouble - people are trying
to fix all issues for a few month's now and every time it results in we
cut
$something then it works! and of course developers as myself start to
shout
that we don't need namespaces half implemented, because they are useless
when.
I took part in discussion in two threads by this time:
here: solving the namespace conflict issues between function/static method
class constant/ns constant
AND
here: true namespaces, yet another point of view
Firstly I also proposed . as a separator, but it has issues with constants:
?php
define('CONST', 'hello ');
class Test {
static function print() {
return 'world!';
}
}
echo CONST.Test::print();
?
That now results in hello world!. So if CONST is a namespace and we have
constant named the same - a problem occures. Well, that can be worked
around
- we can check for name collision and give an error, but I think people
will
shout at that as bad, wy we can't have namespace and constant named equaly?
Well, I would live with that perfectly, but something tells me developers
will be against this.
Other problem is resolution.
MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a
namespace itself?
As I understand, during compile time that isn't a problem to resolve
whether
it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch
isn't a constant, not namespace. Ups, what error should we give? Undefined
constant or missing namespace? Well, as i think of this - only good
solution
is Fatal error, but then any
Re: [PHP-DEV] alpha3
+1 for : from me. Ternary. Operator. Trouble. Otherwise it'd get my vote too. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a): On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; Will _you_ write such code? No. Will anybody from this list write such code? No. Will any good PHP developer write such code? No. So why do you think that's a problem? It would be a problem only for people writing such code, and I think that such people will be able to do something stupid with every syntax. PS. Somebody might also write $a = $b ? $c ? true : false ? true : false : true; Does it mean, that ternary is bad? Of course not. PS2. *I* *personally* like :: much more than : and I think, that conflicting namespaced functions and class functions should just result in an error, as has Vesselin Kenashkov suggested. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On 9/29/08, Stefan Walk [EMAIL PROTECTED] wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; It's only a problem when you use fully qualified names inside a ternary operation, and can easily be fixed with parenthesis in this particular case, so it still looks much better than the current situation to me, and I'm pretty sure everyone would agree on using : as a separator if it weren't from that small glitch. The use of parenthesis is not that big a deal if it's restricted to ternary operator uses, there are some places already where you're forced to use them for disambiguation. We could also keep ::foo() as the way to address the global namespace, which might allow $a ? ::foo() : ::bar() without parenthesis ? I don't know enough about the parser to say though. -- Jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; Will _you_ write such code? No. Will anybody from this list write such code? You may want to write $a = $b?A:B:C and how would php compiler resolve A:B:C? A:B vs C or A vs B:C? To me it's better to stay with :: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Mon, 2008-09-29 at 19:24 +0200, Janusz Lewandowski wrote: Monday 29 September 2008 18:35:45 Stefan Walk napisał(a): On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; Will _you_ write such code? That's not the point. The point is the parser can't easily identify it - we barely care about namespaces, so someClass :: method ( ) ; is as valid as someClass::method(); independent from the context, same should be true for namespaces and their separator independent from the context. ... but well, that was all discussed multiple times before johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Mon, 29 Sep 2008 19:30:00 +0300, Vesselin Kenashkov [EMAIL PROTECTED] wrote: My proposal is (if possible/reasonable/performance wise of course) to have a fatal error thrown when during the parse time the engine discovers duplicates like the one described above. What is the point to name in the same way a class and a static method and a namespace and a function in the same way? In my (very humble) opinion this is the best solution, because we keep the :: operator that we are familiar with, the ambiguity is resolved (just not allowing it) and (I guess) the php 5.3 will not be delayed much. There's nothing familiar about :: to 99.99% of PHP developers who haven't already been playing with the alphas. It has no magical significance in namespace mythos. If the reuse of a symbol is causing problems, change the symbol to one that doesn't cause problems. Finding a symbol that doesn't cause problems may not be a simple task, but please don't pretend that has any special significance to namespaces in concept. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Le lundi 29 septembre 2008 à 13:48 -0500, Larry Garfield a écrit :
On Mon, 29 Sep 2008 19:30:00 +0300, Vesselin Kenashkov [EMAIL PROTECTED]
wrote:
My proposal is (if possible/reasonable/performance wise of course) to have
a
fatal error thrown when during the parse time the engine discovers
duplicates like the one described above. What is the point to name in the
same way a class and a static method and a namespace and a function in the
same way? In my (very humble) opinion this is the best solution, because
we
keep the :: operator that we are familiar with, the ambiguity is resolved
(just not allowing it) and (I guess) the php 5.3 will not be delayed much.
There's nothing familiar about :: to 99.99% of PHP developers who haven't
already been playing with the alphas.
You are forgetting C++ (PHP's oop implementation looks a lot like C++'s
one, and my guess is it was made this way).
Around 40% of the PHP developpers in our team have C++ experience, and
would love to see namespaces in PHP. They don't really care about what
separator is used, but :: is what they already use in C++
You could say C++ is cheating because you *need* to have everything
defined in header files (eg, no autoload) and the lookup is done at
compile time (eg. we can take time to lookup exactly what we are
invoking), so using different operators isn't needed.
Also, unlike . (eg, echo foo.bar will echo foobar because of php's
permissive/compatible behaviour), :: isn't allowed for use anywhere
(unexpected T_PAAMAYIM_NEKUDOTAYIM) and is more suited for namespaces
separations (will not break previously badly-written code).
The current implementation in PHP 5.3.0 is nice, I used it for a few
months (had to adapt my code, like replacing import by use), and I
must say it's working, however if we are to change the namespace
separator by something else, it should have been done 3~4 months ago.
Doing it now may cause problem that we didn't think of in one or two
months, so either PHP 5.3.0 should be delayed and the separator changed,
either it's too late to change that.
Anyway I'd be in favor of the namespace resolution operator stuff like
: (also because it looks like it's smiling ;p )
some::long::namespace:someclass::function();
We see that we have some::long::namespace, and within this namespace we
call function(), which is a method of someclass.
Changing the operator within the namespace is not something wanted, the
goal is to improve calls lookups, and remove ambiguity to avoid cases
like:
namespace foo;
class bar {
function baz() {}
}
namespace foo::bar;
function baz() {}
In this case you have two different functions :
foo:bar::baz();
foo::bar:baz();
In each call, you immediatly see the difference between the namespace
part and the function/class part.
The only part in the implementation which will become a bit more complex
is to resolve a call from a namespace. Eg:
namespace foo;
bar:baz();
bar::baz();
In the first case we need to prefix foo:: and in the second one we
need to prefix foo:.
The good thing is since there's no reason to reference a namespace by
itself, there shouldn't be any problem to guess which separator should
be used.
Mark
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi Greg, The patch I posted here: http://pear.php.net/~greg/ns.element.patch.txt does exactly what you are talking about. For some reason, some people find this too difficult to digest. I've already expressed my opinion on the matter (after all, I did spend almost a week developing the patch). OK, I'll bite. First off, I find '-' just as much as potential source of confusion as '::', and for the exact same reason: it's already used to express a relationship in PHP. All this says to me is we still don't have the right ns separator. It's clear that PHP 5.3 shouldn't go out with '::' as the ns separator even if only classes are supported, despite the fact that the current implementation appears solid in every other respect at that level. It can't go out that way because we already know there will be huge user pressure to extend namespace support beyond classes. This wasn't part of the original remit, but we now know we need to allow for it before ns support is part of an official release. It's equally clear (to me at least) that having two ways to express a namespaced element depending on context would be a Bad Thing [TM]. The only reason that's even come up for consideration is the ambiguity caused by the ns separator we already have. Basically, I think you're trying to find solutions to the wrong problem, since at present ns support doesn't exist in any official PHP release. Your approach assumes a BC consideration that (thankfully) doesn't exist yet. I don't want to see that whole ns separator debate all over again any more than you do, but I really don't see a good way to avoid it... sorry. And if that means introducing a new symbol... it can't really be staved off until 6.0, unless we don't care about 6.0 code not running under 5.3. The other option of course would be to say ns support will **never** be extended beyond classes, and actually mean it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
+1, or: Do, or do not. There is no 'try.' - David On 28.09.2008, at 16:29, Steph Fox wrote: Hi Greg, The patch I posted here: http://pear.php.net/~greg/ns.element.patch.txt does exactly what you are talking about. For some reason, some people find this too difficult to digest. I've already expressed my opinion on the matter (after all, I did spend almost a week developing the patch). OK, I'll bite. First off, I find '-' just as much as potential source of confusion as '::', and for the exact same reason: it's already used to express a relationship in PHP. All this says to me is we still don't have the right ns separator. It's clear that PHP 5.3 shouldn't go out with '::' as the ns separator even if only classes are supported, despite the fact that the current implementation appears solid in every other respect at that level. It can't go out that way because we already know there will be huge user pressure to extend namespace support beyond classes. This wasn't part of the original remit, but we now know we need to allow for it before ns support is part of an official release. It's equally clear (to me at least) that having two ways to express a namespaced element depending on context would be a Bad Thing [TM]. The only reason that's even come up for consideration is the ambiguity caused by the ns separator we already have. Basically, I think you're trying to find solutions to the wrong problem, since at present ns support doesn't exist in any official PHP release. Your approach assumes a BC consideration that (thankfully) doesn't exist yet. I don't want to see that whole ns separator debate all over again any more than you do, but I really don't see a good way to avoid it... sorry. And if that means introducing a new symbol... it can't really be staved off until 6.0, unless we don't care about 6.0 code not running under 5.3. The other option of course would be to say ns support will **never** be extended beyond classes, and actually mean it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] alpha3
Steph Fox wrote: I don't want to see that whole ns separator debate all over again any more than you do, but I really don't see a good way to avoid it... sorry. +1, I second this completely From someone who *was* using namespaces developing against the 5.3 branch, this is going to happen sooner or later. I found that :: just causes to many questions when used in namespaces. Using :: or - just for the sake of reusing existing tokens is just wrong. I'm in favor of # if it can be worked out. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Sat, Sep 27, 2008 at 8:10 AM, Greg Beaver [EMAIL PROTECTED] wrote: I have to respectfully disagree with both of you: Stas: choosing an imperfect solution when a better one already exists is just plain stupid, and isn't what you want *or* what you suggested - the solution you, Liz, Marcus and Andi proposed is not imperfect, it is consistent, robust and far better than the existing CVS implementation of namespaces. Don't sell yourself so short! :) Steph: the limited solution proposed by Stas and company (removing functions [and I would add constants]/fixing name resolution) *is* a basic solution that can be expanded on. I outlined the steps in my reply. It's the best solution to the problem, not an imperfect one. A namespace solution that works brilliantly for classes will satisfy at least 2/3 of the users who want it. I guess, I am in these 2/3's. Limited solution (with a promise to extend it later) would work for me, perfectly. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
I would definitely have to agree. I would much prefer to have a minimal solution implemented and then to iterate over it in the future than to try to figure out the perfect implementation the first time. Just from watching where the thread about namespaces has gone, I would definitely have to say that we have set the expectation for ourselves that the first implementation will be the only one and therefore has to be perfect. And that's hard to live up to :) Ilia On Sat, Sep 27, 2008 at 1:45 AM, Alexey Zakhlestin [EMAIL PROTECTED]wrote: On Sat, Sep 27, 2008 at 8:10 AM, Greg Beaver [EMAIL PROTECTED] wrote: I have to respectfully disagree with both of you: Stas: choosing an imperfect solution when a better one already exists is just plain stupid, and isn't what you want *or* what you suggested - the solution you, Liz, Marcus and Andi proposed is not imperfect, it is consistent, robust and far better than the existing CVS implementation of namespaces. Don't sell yourself so short! :) Steph: the limited solution proposed by Stas and company (removing functions [and I would add constants]/fixing name resolution) *is* a basic solution that can be expanded on. I outlined the steps in my reply. It's the best solution to the problem, not an imperfect one. A namespace solution that works brilliantly for classes will satisfy at least 2/3 of the users who want it. I guess, I am in these 2/3's. Limited solution (with a promise to extend it later) would work for me, perfectly. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi Greg, Steph: the limited solution proposed by Stas and company (removing functions [and I would add constants]/fixing name resolution) *is* a basic solution that can be expanded on. I outlined the steps in my reply. It's the best solution to the problem, not an imperfect one. A namespace solution that works brilliantly for classes will satisfy at least 2/3 of the users who want it. Great! So why isn't it already in CVS? Adding support for functions, constants and even variables is actually quite do-able with the solution I suggested (different separator between namespace name and function/constant/variable name) and can be added easily. Ah that's why it isn't already in. I agree with you that this would be a workable solution for 99% of the problems uncovered so far, but... man, it's fugly! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Adding support for functions, constants and even variables is actually quite do-able with the solution I suggested (different separator between namespace name and function/constant/variable name) and can be added easily. Adding support for functions, constants and even variables is actually quite do-able with the solution I suggested (different separator between namespace name and function/constant/variable name) and can be added easily. Greg, Does it mean that the namespace separator will not be (or likely not to be) the same when you need access to namespaced classes vs namespaced functions? What's about consistency of the design? If you can't resolve the ambiguity or any other problems around namespaces without changing the separator, why not to change it for classes too? -JV -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
jvlad wrote: Adding support for functions, constants and even variables is actually quite do-able with the solution I suggested (different separator between namespace name and function/constant/variable name) and can be added easily. Adding support for functions, constants and even variables is actually quite do-able with the solution I suggested (different separator between namespace name and function/constant/variable name) and can be added easily. Greg, Does it mean that the namespace separator will not be (or likely not to be) the same when you need access to namespaced classes vs namespaced functions? What's about consistency of the design? If you can't resolve the ambiguity or any other problems around namespaces without changing the separator, why not to change it for classes too? Hi, The patch I posted here: http://pear.php.net/~greg/ns.element.patch.txt does exactly what you are talking about. For some reason, some people find this too difficult to digest. I've already expressed my opinion on the matter (after all, I did spend almost a week developing the patch). Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hey Lukas, Johannes, all... We are not yet ready to schedule alpha3, but I am hoping we can do it in the first half of October. This is just a heads up to tell everybody that yes there will be an alpha3 and a general timeframe. This is not an invitation to go crazy and start committing features at all. If you have something that you think is very low risk, unquestionably useful, with ready tests and patches, then feel free to approach me and Johannes. Otherwise just help us to get 5.3.0 out the door, so that you can add whatever niceties into 5.3.1 :) Does that mean we can drop namespace support until 6.0? Please? Rationale: 1) It's uber-contentious, and all the good stuff's only just starting to turn up that would allow sane design decisions 2) If it's released as-is, there would be no going back due to BC concerns Simple as. I'm just worried about it all, and 5.3 should've been out months ago because it's otherwise brilliant. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi! Does that mean we can drop namespace support until 6.0? Please? Rationale: 1) It's uber-contentious, and all the good stuff's only just starting to turn up that would allow sane design decisions I don't know what uber-contentios means, but no solution is going to satisfy 100% of people. The solution we have now is good for many uses, even if not for 100% of them, and delaying this much needed feature because of couple of vocal people of the list is just insane. 2) If it's released as-is, there would be no going back due to BC concerns Going back to what? To endless discussions about separator characters? No, we are not, and good riddance. Imperfect solution is much better than perpetual absence of any solution. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Oh Stas, we have to fall out now! Imperfect solution is much better than perpetual absence of any solution. See, I'm not sure I agree with that. I think 'imperfect but basic solution that can be expanded on' would be a better approach than trying to do it all in one hit. And I still think putting it off to PHP 6 would be a smart move. It's the major thing that's holding up 5.3. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi! And I still think putting it off to PHP 6 would be a smart move. It's the major thing that's holding up 5.3. Nothing is holding anything. Lukas has release schedule, and namespace implementation will fit it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Steph Fox wrote:
Oh Stas, we have to fall out now!
Imperfect solution is much better than perpetual absence of any solution.
See, I'm not sure I agree with that.
I think 'imperfect but basic solution that can be expanded on' would be
a better approach than trying to do it all in one hit.
And I still think putting it off to PHP 6 would be a smart move. It's
the major thing that's holding up 5.3.
Hi,
I have to respectfully disagree with both of you:
Stas: choosing an imperfect solution when a better one already exists is
just plain stupid, and isn't what you want *or* what you suggested - the
solution you, Liz, Marcus and Andi proposed is not imperfect, it is
consistent, robust and far better than the existing CVS implementation
of namespaces. Don't sell yourself so short! :)
Steph: the limited solution proposed by Stas and company (removing
functions [and I would add constants]/fixing name resolution) *is* a
basic solution that can be expanded on. I outlined the steps in my
reply. It's the best solution to the problem, not an imperfect one. A
namespace solution that works brilliantly for classes will satisfy at
least 2/3 of the users who want it.
Adding support for functions, constants and even variables is actually
quite do-able with the solution I suggested (different separator between
namespace name and function/constant/variable name) and can be added easily.
file 1:
?php
namespace foo::bar;
class myclass {}
function myfunc()(}
var $myvar;
const myconst = 1;
?
file 2:
?php
include 'file1.php';
$a = new foo::bar::myclass;
foo::bar:myfunc; // separator : could be anything
echo foo::bar:$myvar;
echo foo::bar:myconst;
// all of the below would also be possible, although we may choose not
to implement things like use of a variable
use foo::bar::myclass, foo::bar:$myvar, foo::bar:myfunc(),
foo::bar:myconst, foo::bar;
?
So the question of whether we are making a mistake with Stas's
suggestion relayed from ZendCon is debunked by 2 facts:
1) the implementation is a reduced set based on the existing namespace
implementation which has been beaten up and tested thoroughly, and
because it is simpler, will be even easier to verify its veracity.
2) it can be easily extended to add support later for other components
like functions, while preserving 100% BC with the current::implementation.
There is also jvlad's suggestion to consider, but in my opinion, this
trades one conflict for another, as this code would be a fatal error:
?php
namespace http;
class Request {}
namespace http::request; // fatal error - name conflict between class
http::request and namespace http::request
class body {}
?
Unless we also used my suggestion of having a namespace member separator
different from scope resolution operator.
In addition, Rasmus has pointed out many times in the past that allowing
changing the namespace of external code depending on code load order
would simply break opcode caching for PHP.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
