Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 5.1 »

PHP 5.1

php.internals

Andi Gutmans

21 years ago
Hey, There have been a lot of questions and discussion regarding status of PHP 5.1. In the past few weeks, many have been fixing lots of bugs and PDO seems to have reached a pretty stable state. In parallel, a lot of work has been done offline by Andrei, Dmitry and others, to enable Unicode support in PHP and the Zend Engine. I believe it is time now to move 5.1 forward at a much faster pace. I'd like to roll a beta of it towards the end of next week such as Thursday (giving a chance for some last minute fixes), and then hopefully RC within a week or two. Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make HEAD the Unicode development stream (merging Unicode changes into HEAD). Hopefully, by going at this pace, we can have a pretty decent Unicode version of PHP out there within a few months; and have PDO out there almost immediately. So I envision: End of June - PHP 5.1. Main feature PDO, Improved ZEII and other improvements. Q3.2005 - Beta of PHP 5.5/6.0 featuring Unicode support. Thanks, Andi

Greg Beaver

21 years ago
Andi Gutmans wrote:
> Hey, > > There have been a lot of questions and discussion regarding status of > PHP 5.1. > In the past few weeks, many have been fixing lots of bugs and PDO seems > to have reached a pretty stable state. > In parallel, a lot of work has been done offline by Andrei, Dmitry and > others, to enable Unicode support in PHP and the Zend Engine. > I believe it is time now to move 5.1 forward at a much faster pace. I'd > like to roll a beta of it towards the end of next week such as Thursday > (giving a chance for some last minute fixes), and then hopefully RC > within a week or two. > Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make HEAD the > Unicode development stream (merging Unicode changes into HEAD). > > Hopefully, by going at this pace, we can have a pretty decent Unicode > version of PHP out there within a few months; and have PDO out there > almost immediately. > > So I envision: > End of June - PHP 5.1. Main feature PDO, Improved ZEII and other > improvements. > Q3.2005 - Beta of PHP 5.5/6.0 featuring Unicode support.
Judging by the importance of the 5.5/6.0 release, I think shooting for a stable PEAR 1.4.0 in that release would make sense as well. I will of course run this by the other PEAR folks since they probably care a little more about the details of this decision :). It will not be ready for a stable release in a week or two, there's still some wrangling over features. One thing to note: I've been working on PHP_Archive with Davey Shafik, which will allow PEAR to be distributed in a single file, and this means the CVS sync nightmare that is PEAR in the unix build can be eliminated by this solution. This also will not be ready in a week or two, so 5.5/6.0 it is. Thanks, Greg

Andi Gutmans

21 years ago
Sounds good. At 10:07 AM 6/4/2005 -0400, Greg Beaver wrote:

Magnus Maatta

21 years ago
Hi Andi, On Saturday 04 June 2005 07.58, Andi Gutmans wrote:
> I'd like to roll a beta of it towards the end of next week such as > Thursday (giving a chance for some last minute fixes), and then > hopefully RC within a week or two. > Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make > HEAD the Unicode development stream (merging Unicode changes into > HEAD).
What about ifsetor for 5.1 ?
> So I envision: > End of June - PHP 5.1. Main feature PDO, Improved ZEII and other > improvements. Q3.2005 - Beta of PHP 5.5/6.0 featuring Unicode > support.
And the much needed goto for the next one (5.2/5.5/6.0 or whatever it will be) ? And please, no "this and that professor told me/wrote/said goto is bad", and so on, replies =) Magnus Määttä
-- jogger, n.: An odd sort of person with a thing for pain.

Jani Taskinen

21 years ago
On Sun, 5 Jun 2005, Magnus Määttä wrote:
> Hi Andi, > > On Saturday 04 June 2005 07.58, Andi Gutmans wrote: >> I'd like to roll a beta of it towards the end of next week such as >> Thursday (giving a chance for some last minute fixes), and then >> hopefully RC within a week or two. >> Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make >> HEAD the Unicode development stream (merging Unicode changes into >> HEAD). > > What about ifsetor for 5.1 ?
+1000
> And the much needed goto for the next one (5.2/5.5/6.0 or whatever it > will be) ?
I've found a lot of cases where this would have been nice to have and simplified the code too.. So +1 from me. (wasn't there a patch for this already somewhere?) --Jani

Magnus Maatta

21 years ago
On Monday 06 June 2005 00.13, Jani Taskinen wrote:
> On Sun, 5 Jun 2005, Magnus Määttä wrote: > > And the much needed goto for the next one (5.2/5.5/6.0 or > > whatever it will be) ? > > I've found a lot of cases where this would have been nice to > have and simplified the code too.. > > So +1 from me. (wasn't there a patch for this already > somewhere?)
Yes, Sara made a patch for it.. http://pecl.org/patches/opcode_goto_5.1.0.diff I don't know if this is the latest one or not. Magnus Määttä
-- I cannot and will not cut my conscience to fit this year's fashions. -- Lillian Hellman

Ilia A.

21 years ago
> Yes, Sara made a patch for it.. > http://pecl.org/patches/opcode_goto_5.1.0.diff > I don't know if this is the latest one or not.
+1 for the goto patch in 5.1 Ilia

Olivier Hill

21 years ago
Hi, I'm +1 on the goto patch aswell. What was the consent on the limit of a goto statement? Should it be able to jump outside a control block? Can it jump anywhere? Sincerely, Olivier On 6/5/05, Ilia Alshanetsky <ilia@prohost.org> wrote:

Mike Robinson

21 years ago
Olivier Hill wrote:
> Hi, > > I'm +1 on the goto patch aswell. What was the consent on the > limit of a goto statement? Should it be able to jump outside > a control block? > Can it jump anywhere?
And there are many more questions and issues just like this that expose the ugliness of what would _appear_ to be a handy feature. I don't pack any weight on this list so if someone with a -1 on this feature would like to kick it up to -2 I'd appreciate it. =) Best Regards Mike Robinson

Stanislav Malyshev

21 years ago
MR>>expose the ugliness of what would _appear_ to be a handy feature. I MR>>don't pack any weight on this list so if someone with a -1 on this MR>>feature would like to kick it up to -2 I'd appreciate it. I'm not sure why goto should be needed after many years of successful life without it. I think parametrized break/continue takes care of all cases when I would need goto in C, so I think goto is not needed. In any case, goto in/out of the control block in an invitation to hell, since it would mess up a lot of assumptions and can lead to crashes/leaks. So I personally don't particularly like this idea.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Derick Rethans

21 years ago
On Mon, 6 Jun 2005, Stanislav Malyshev wrote:
> MR>>expose the ugliness of what would _appear_ to be a handy feature. I > MR>>don't pack any weight on this list so if someone with a -1 on this > MR>>feature would like to kick it up to -2 I'd appreciate it. > > I'm not sure why goto should be needed after many years of successful life > without it. I think parametrized break/continue takes care of all cases > when I would need goto in C, so I think goto is not needed. In any case, > goto in/out of the control block in an invitation to hell, since it would > mess up a lot of assumptions and can lead to crashes/leaks. So I > personally don't particularly like this idea.
We're only talking about a goto that: - can only jump to a static label - can only jump inside the current scope With a parameterized break/continue you still can't just to the "end" of your function to do clean ups (unless you wrap it in a control block which is ugly and already possible anyway). Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Stanislav Malyshev

21 years ago
DR>>We're only talking about a goto that: DR>>- can only jump to a static label DR>>- can only jump inside the current scope DR>> DR>>With a parameterized break/continue you still can't just to the "end" of DR>>your function to do clean ups (unless you wrap it in a control block finally construct should do that, I think. IMO that's the right solution, not goto's - and anyway if you allow goto only inside same block, what if error condition happens inside other block? Are all your functions flat without control blocks? What if exception happens - are you not going to clean up then? And if you allow goto's to jump out of control blocks, all kinds of non nice things can happen - e.g. not cleaning up variables if engine planned to clean them up later in the block. And you still have problem with exceptions. DR>>which is ugly and already possible anyway). Using control blocks is no more ugly than using goto's - and thr right way to do it is using exception handling and finally, IMO.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Petar Nedyalkov

21 years ago
On Monday 06 June 2005 14:37, Derick Rethans wrote:
> On Mon, 6 Jun 2005, Stanislav Malyshev wrote: > > MR>>expose the ugliness of what would _appear_ to be a handy feature. I > > MR>>don't pack any weight on this list so if someone with a -1 on this > > MR>>feature would like to kick it up to -2 I'd appreciate it. > > > > I'm not sure why goto should be needed after many years of successful > > life without it. I think parametrized break/continue takes care of all > > cases when I would need goto in C, so I think goto is not needed. In any > > case, goto in/out of the control block in an invitation to hell, since it > > would mess up a lot of assumptions and can lead to crashes/leaks. So I > > personally don't particularly like this idea. > > We're only talking about a goto that: > - can only jump to a static label > - can only jump inside the current scope > > With a parameterized break/continue you still can't just to the "end" of > your function to do clean ups (unless you wrap it in a control block > which is ugly and already possible anyway).
I think it's OK. All objections agains 'goto' are not based on it's existence but on it's use. So restricting the use to a static label in the current scope is fine. If you don't like using it (as most of us have been taught in our CS lectures) - simply don't use it. +1 for me.
> > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org
-- Cyberly yours, Petar Nedyalkov Devoted Orbitel Fan :-) PGP ID: 7AE45436 PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436

Petar Nedyalkov

21 years ago
On Monday 06 June 2005 14:37, Derick Rethans wrote:
> On Mon, 6 Jun 2005, Stanislav Malyshev wrote: > > MR>>expose the ugliness of what would _appear_ to be a handy feature. I > > MR>>don't pack any weight on this list so if someone with a -1 on this > > MR>>feature would like to kick it up to -2 I'd appreciate it. > > > > I'm not sure why goto should be needed after many years of successful > > life without it. I think parametrized break/continue takes care of all > > cases when I would need goto in C, so I think goto is not needed. In any > > case, goto in/out of the control block in an invitation to hell, since it > > would mess up a lot of assumptions and can lead to crashes/leaks. So I > > personally don't particularly like this idea. > > We're only talking about a goto that: > - can only jump to a static label > - can only jump inside the current scope > > With a parameterized break/continue you still can't just to the "end" of > your function to do clean ups (unless you wrap it in a control block > which is ugly and already possible anyway).
I think it's OK. All objections agains 'goto' are not based on it's existence but on it's use. So restricting the use to a static label in the current scope is fine. If you don't like using it (as most of us have been taught in our CS lectures) - simply don't use it. +1 for me.
> > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org
-- Cyberly yours, Petar Nedyalkov Devoted Orbitel Fan :-) PGP ID: 7AE45436 PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436

Magnus Maatta

21 years ago
Hi Stanislav, On Monday 06 June 2005 13.33, Stanislav Malyshev wrote:
> I'm not sure why goto should be needed after many years of > successful life without it. I think parametrized break/continue > takes care of all cases when I would need goto in C, so I think > goto is not needed.
People are talking about hypothetical messy code because of goto, but the current situation is even *worse*. I have some code that I have had to rewrite several times just because all those nested loops with different levels of break and continue is extremely hard to follow. Using recursive functions is not an option, as Ilia already said - it will just crash PHP. Exceptions ? No thank you, even worse then continue/break.. Magnus Määttä
-- A kiss is a course of procedure, cunningly devised, for the mutual stoppage of speech at a moment when words are superfluous.

Stanislav Malyshev

21 years ago
MM>>Exceptions ? No thank you, even worse then continue/break.. Why is it worse? That's something that I don't understand - why people think exceptions, which have clear structured mechanism of using them, are worse than goto which has no safeguards at all and allows to do a lot of messy things. What's the problem with exceptions?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Andrey Hristov

21 years ago
Quoting Ilia Alshanetsky <ilia@prohost.org>:
>> Yes, Sara made a patch for it.. >> http://pecl.org/patches/opcode_goto_5.1.0.diff >> I don't know if this is the latest one or not. > > +1 for the goto patch in 5.1 > > Ilia > > -- PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
+1 from here too Andrey

Sascha Schumann

21 years ago
> So +1 from me. (wasn't there a patch for this already somewhere?)
PHP has enough horrid language misfeatures. It does not need another one. Seeing the potential damage of adding goto to the language, I can only give it a -1. - Sascha

Mark Krenz

21 years ago
I agree I give it a -1 too. On Mon, Jun 06, 2005 at 07:04:56AM GMT, Sascha Schumann [sascha@schumann.cx] said the following:
> > So +1 from me. (wasn't there a patch for this already somewhere?) > > PHP has enough horrid language misfeatures. It does not need > another one. Seeing the potential damage of adding goto to > the language, I can only give it a -1. > > - Sascha > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/

Derick Rethans

21 years ago
On Mon, 6 Jun 2005, Jani Taskinen wrote:
> > And the much needed goto for the next one (5.2/5.5/6.0 or whatever it > > will be) ? > > I've found a lot of cases where this would have been nice to have > and simplified the code too.. > > So +1 from me. (wasn't there a patch for this already somewhere?)
For me too: +1. Derick

George Schlossnagle

21 years ago
On Jun 6, 2005, at 3:09 AM, Derick Rethans wrote:
> On Mon, 6 Jun 2005, Jani Taskinen wrote: > > >>> And the much needed goto for the next one (5.2/5.5/6.0 or >>> whatever it >>> will be) ? >> So +1 from me. (wasn't there a patch for this already somewhere?) > For me too: +1.
+1 here as well. George

Ondrej Ivanič

21 years ago
Jani Taskinen wrote:
>> And the much needed goto for the next one (5.2/5.5/6.0 or whatever it >> will be) ? > I've found a lot of cases where this would have been nice to have > and simplified the code too.. > > So +1 from me. (wasn't there a patch for this already somewhere?)
When I move from functional to OO or generic programing I don't need use 'goto' statement anymore. I think, better (cleaner) way is extend 'break' and 'continue' to accept string as label name in local scope. (like java :)). Implement 'goto' with possibility to jump anywhere is a step backwards... So -1 from me to goto.
-- Ondrej Ivanic (ondrej@kmit.sk)

Derick Rethans

21 years ago
On Mon, 6 Jun 2005, Ondrej Ivanič wrote:
> Jani Taskinen wrote: > >> And the much needed goto for the next one (5.2/5.5/6.0 or whatever it > >> will be) ? > > I've found a lot of cases where this would have been nice to have > > and simplified the code too.. > > > > So +1 from me. (wasn't there a patch for this already somewhere?) > > When I move from functional to OO or generic programing I don't need use > 'goto' statement anymore. > > I think, better (cleaner) way is extend 'break' and 'continue' to accept > string as label name in local scope. (like java :)). > > Implement 'goto' with possibility to jump anywhere is a step backwards...
It's exactly the same as "break <label>"... goto can only jump in the same scope with a label. So I don't see the difference. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Ondrej Ivanič

21 years ago
Derick Rethans wrote:
>>I think, better (cleaner) way is extend 'break' and 'continue' to accept >>string as label name in local scope. (like java :)). >> >>Implement 'goto' with possibility to jump anywhere is a step backwards... > > > It's exactly the same as "break <label>"... goto can only jump in the > same scope with a label. So I don't see the difference. > > Derick >
It's not same, but it's same, look: for( ... ) { while( ... ) { if(cond) goto exit; } } exit: is equivalent with: exit: for( ... ) { while( ... ) { if(cond) break exit; } } or for( ... ) { while( ... ) { if(cond) break 2; } } goto <label>: - we can jump into another loop, not so good break/continue <label> - little confusing syntax: break terminate executing labeled statement and transfer control to the next statement. I don't need 'goto' but I prefer to extend break/continue. Always if possible to set a flag in loop and use it to escape... :) goto can help, but mostly create unreadable code...
-- Ondrej Ivanic (ondrej@kmit.sk)

Stanislav Malyshev

21 years ago
OI>>break/continue <label> OI>>- little confusing syntax: break terminate executing labeled statement OI>>and transfer control to the next statement. I can see a value in this one, if it can be implemented correctly, meaning it won't allow just jumping around but only exiting blocks and label would be used just not to count blocks. I don't know if it can work good, but if it can - it's OK with me.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Christian Schneider

21 years ago
Magnus Määttä wrote:
> And the much needed goto for the next one (5.2/5.5/6.0 or whatever it will be) ?
Much needed? Matter of taste as lots of existing PHP code proves :-) What happens if you goto into a loop? I'd rather avoid this mess. -1 from me. - Chris

Magnus Maatta

21 years ago
On Monday 06 June 2005 11.01, Christian Schneider wrote:
> Magnus Määttä wrote: > > And the much needed goto for the next one (5.2/5.5/6.0 or > > whatever it will be) ? > > Much needed? Matter of taste as lots of existing PHP code proves > :-) What happens if you goto into a loop? I'd rather avoid this > mess.
Matter of taste, I'm not so sure about that. If you have a taste for unmaintainable code to emulate goto, sure, goto isn't something you want then. But I sure as hell don't want to maintain even my own code. See me earlier reply to Stanislav, I just proved my point on IRC just after sending the mail.. Missed a few recursive function calls and several loops. And I didn't even try to understand all logic, just get the relevant parts out of the code. Unmaintainable is the keyword. Magnus Määttä
-- <Thoth_> Yeah, well that's why it's numbered 2.3.1... it's for those of us who miss NT-like uptimes

Marcus Boerger

21 years ago
Hello Magnus, Monday, June 6, 2005, 6:41:49 PM, you wrote:
> On Monday 06 June 2005 11.01, Christian Schneider wrote: >> Magnus Määttä wrote: >> > And the much needed goto for the next one (5.2/5.5/6.0 or >> > whatever it will be) ? >> >> Much needed? Matter of taste as lots of existing PHP code proves >> :-) What happens if you goto into a loop? I'd rather avoid this >> mess.
> Matter of taste, I'm not so sure about that. If you have a taste for > unmaintainable code to emulate goto, sure, goto isn't something you > want then. But I sure as hell don't want to maintain even my own > code.
Wrong code layout then. However the question is whether we finally want to support the usual way compiler generators work. Since those only require local goto i am + 1 on the mentioned limited version from Sara/Andi marcus

Wez Furlong

21 years ago
On 6/5/05, Magnus Määttä <magnus@php.net> wrote:
> And the much needed goto for the next one (5.2/5.5/6.0 or whatever it > will be) ?
+1 (for the "limited" version that Sara and Andi already worked out last time this came up)
> And please, no "this and that professor told me/wrote/said goto is > bad", and so on, replies =)
Amen :) --Wez.

Ron Korving

21 years ago
"Magnus Määttä" <magnus@php.net> wrote in message news:200506051859.53976.magnus@php.net...
> What about ifsetor for 5.1 ?
Would anybody be interested in a parameter for ifsetor() that would treat isset() as !empty() or an alternative function that achieves this? I know I'd love to see that. I use empty() a lot more than isset().

Sara Golemon

21 years ago
> > What about ifsetor for 5.1 ? > > Would anybody be interested in a parameter for ifsetor() that would treat > isset() as !empty() or an alternative function that achieves this? I know > I'd love to see that. I use empty() a lot more than isset(). >
In the interrest of KISS, I'd leave the emptiness concept out of the picture. Unlike isset-ness, an emptiness coalesce *can* be done in userspace: function firstNotEmpty() { $vars = func_get_args(); foreach($vars as $var) if (!empty($var)) return $var; return NULL; } There's enough....contention over the undeniably useful and not-implementable-in-userspace parts of this thread that it's not worth muddling it up with things that are a simple matter to do in userspace. It doesn't matter that notempty() and ifsetor() could easily be implemented by the same opcode (just like isset/empty are). -Sara

Ron Korving

21 years ago
The problem with your example of firstNotEmpty() would be that if a variable is not set, I'll get a notice, which I don't want. So it's really no different from an isset() check. You want to be able to apply it to an variable that is not yet set. Ron ""Sara Golemon"" <pollita@php.net> wrote in message news:38.CE.21296.BFD78A24@pb1.pair.com...
> > > What about ifsetor for 5.1 ? > > > > Would anybody be interested in a parameter for ifsetor() that would
treat
> > isset() as !empty() or an alternative function that achieves this? I
know
> > I'd love to see that. I use empty() a lot more than isset(). > > > In the interrest of KISS, I'd leave the emptiness concept out of the > picture. Unlike isset-ness, an emptiness coalesce *can* be done in > userspace: > > function firstNotEmpty() { > $vars = func_get_args(); > foreach($vars as $var) > if (!empty($var)) return $var; > return NULL; > } > > There's enough....contention over the undeniably useful and > not-implementable-in-userspace parts of this thread that it's not worth > muddling it up with things that are a simple matter to do in userspace.
It
> doesn't matter that notempty() and ifsetor() could easily be implemented
by

Ron Korving

21 years ago
If it were possible at all to make a function accept unset variables without generating a notice, I think ifsetor() shouldn't even be implemented. People could then have the freedom to create such functions themselves. But unfortunately, it doesn't seem to be possible, unless you'd suppress every function call with a @, which I don't think is the way to go in this case. So if it would be possible somehow to create your own isset()-like functions in PHP-code, I'd say implement something that would make that possible, and ingore the whole ifsetor() discussion from that moment on. People would be free to write whatever function they'd prefer. Ron ""Sara Golemon"" <pollita@php.net> wrote in message news:38.CE.21296.BFD78A24@pb1.pair.com...
> > > What about ifsetor for 5.1 ? > > > > Would anybody be interested in a parameter for ifsetor() that would
treat
> > isset() as !empty() or an alternative function that achieves this? I
know
> > I'd love to see that. I use empty() a lot more than isset(). > > > In the interrest of KISS, I'd leave the emptiness concept out of the > picture. Unlike isset-ness, an emptiness coalesce *can* be done in > userspace: > > function firstNotEmpty() { > $vars = func_get_args(); > foreach($vars as $var) > if (!empty($var)) return $var; > return NULL; > } > > There's enough....contention over the undeniably useful and > not-implementable-in-userspace parts of this thread that it's not worth > muddling it up with things that are a simple matter to do in userspace.
It
> doesn't matter that notempty() and ifsetor() could easily be implemented
by

Robert Cummings

21 years ago
On Mon, 2005-06-13 at 16:23, Ron Korving wrote:
> If it were possible at all to make a function accept unset variables without > generating a notice, I think ifsetor() shouldn't even be implemented. People > could then have the freedom to create such functions themselves. But > unfortunately, it doesn't seem to be possible, unless you'd suppress every > function call with a @, which I don't think is the way to go in this case. > > So if it would be possible somehow to create your own isset()-like functions > in PHP-code, I'd say implement something that would make that possible, and > ingore the whole ifsetor() discussion from that moment on. People would be > free to write whatever function they'd prefer.
Voila! function ifsetordefault( $array, $key, $default=null ) { if( isset( $array[$key] ) ) { return $array[$key]; } return $default; } echo ifsetordefault( array( 1 => 'One', 2 => 'Two' ), 3, 'Three' ); Or if you prefer: function ifsetpathordefault( $array, $path, $default=null, $sep='/' ) { $pathBits = explode( $sep, $path ); $nest = $array; foreach( $pathBits as $pathBit ) { if( !isset( $nest[$pathBit] ) ) { return $default; } $nest = $nest[$pathBit]; } return $nest; } And yet, I'd still prefer an internal function to do this MUCH MUCH MUCH faster and then I'd also never need to run across the problem of naming collisions with other libraries that implement the same code :) Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Noah Botimer

21 years ago
Rob, I agree with you entirely. It's possible to write this code probably a hundred different ways which, to me, also noting the number of posts the topic has generated, indicates that it should be supported in the language. A common convention for a common operation seems like a sensible goal to me. As nice as it is to be able to roll your own, code sharing is facilitated when we include de facto behaviors. The single implementation close to the metal would also help with speed and code verifiability. Thanks, -Noah On Jun 13, 2005, at 6:33 PM, Robert Cummings wrote:

Jason Garber

21 years ago
Hello Noah, In general, the people who advocate writing this construct differently, are missing the point. ifsetor is NOT input filtering, it is not a complex, general purpose do-everything construct, it is a simple replacement for $x = (isset($ANY_var) ? $ANY_var : 'Default Value'); $x = ifsetor($ANY_var, 'Default Value'); It needs to be fast, and simple. Using @ is not acceptable, because it still entails a call to the custom error handler function. It ought to be able to handle any type. It will be a much-used, not-needed language construct that will speed up PHP, produce cleaner code, and encourage the adoption of E_ALL error reporting. Thanks.
-- Best regards, Jason mailto:jason@ionzoft.com Monday, June 13, 2005, 8:23:17 PM, you wrote: NB> Rob, NB> I agree with you entirely. It's possible to write this code probably NB> a hundred different ways which, to me, also noting the number of NB> posts the topic has generated, indicates that it should be supported NB> in the language. A common convention for a common operation seems NB> like a sensible goal to me. As nice as it is to be able to roll your NB> own, code sharing is facilitated when we include de facto behaviors. NB> The single implementation close to the metal would also help with NB> speed and code verifiability. NB> Thanks, NB> -Noah NB> On Jun 13, 2005, at 6:33 PM, Robert Cummings wrote:

Ondrej Ivanič

21 years ago
Jason Garber wrote:
> ifsetor is NOT input filtering, it is not a complex, general purpose
stuff like 'ifsetof()' is good when is use as:
> $x = ifsetor($ANY_var, 'Default Value');
but too many times I need additional checks like this: $x = isset($_REQUEST['x']) && is_number($x) ? $_REQUEST['x'] : null; It's possible to add additional third parameter to ifsetof() ? ifsetof(variable, expression [, callback]) callback is a function which take one argument (value of variable) and return true or false. If return false 'expression' will be return from ifsetor(). Usage: $x = ifsetor($_REQUEST['x'], null, 'is_number');
> It needs to be fast, and simple.
Hm... It's simple, but It's not very clean at first look. What's your opinion?
-- Ondrej Ivnaic (ondrej@kmit.sk)

Noah Botimer

21 years ago
Ondrej and Jason, Just pondering the proposed coalesce() variants in the context of Ondrej's scenario I came upon two thoughts. I forgot to mention the nice single parameter case of a coalesce() function like this, which would return null if not set: $x = coalesce($REQUEST['x']); Also, the same characteristics could be easily preserved, as far as warnings and errors, by not passing any unset variables to the callback in a ucoalesce() function call: $x = ucoalesce("is_number", $REQUEST['x']); With that assertion, is_number() would only be called if the request variable were set, otherwise returning null, modeling the ternary expression you included, Ondrej. Thanks, -Noah On Jun 14, 2005, at 12:08 AM, Ondrej Ivanič wrote:

Noah Botimer

21 years ago
Jason, I realize that the initial focus is for a simple replacement for a ternary operation. However, I think it should be possible to make a more flexible construct to address more concerns without sacrificing much simplicity or performance, especially in an analogous case. For example: $x = coalesce($_POST['a_radio_group'], -1); $x = coalesce($_POST['optional'], $settings['user_default'], $config ['global_default']); function greaterthan2($val) { return $val > 2; } $x = ucoalesce("greaterthan2", $choice1, $choice2, $choice3); With the addition of a form supporting a callback (set/unset/warning issues would apply), the user could determine what check he needed to perform, in the spirit of things like usort() and array_map(). Like you say, I may be missing the point, but I think a language- level construct to address more needs than fewer would be beneficial to performance AND de facto coding behaviors. Thanks, -Noah On Jun 13, 2005, at 9:44 PM, Jason Garber wrote:

Ron Korving

21 years ago
Jason, you are absolutely right.. this is not about input filtering at all. It's about replacing: $x = (isset($ANY_var) ? $ANY_var : 'Default Value'); by $x = ifsetor($ANY_var, 'Default Value'); So, Robert's solution is no real solution if you ask me. But again, it would be best, if there was no ifsetor() at all, but that users would have the power to create such a function themselves in the php code space. I have no clue how though... Perhaps with syntax like this or something: function ifsetor(@&$var, $default) { return (isset($var)) ? $var : $default; } Though that seems kinda gross, as a syntax it could work ;) Ron "Jason Garber" <jason@ionzoft.com> wrote in message news:87728790.20050613214458@ionzoft.com...

Robert Cummings

21 years ago
On Tue, 2005-06-14 at 01:31, Ron Korving wrote:
> Jason, you are absolutely right.. this is not about input filtering at all. > It's about replacing: > > $x = (isset($ANY_var) ? $ANY_var : 'Default Value'); > by > $x = ifsetor($ANY_var, 'Default Value'); > > So, Robert's solution is no real solution if you ask me. But again, it would > be best, if there was no ifsetor() at all, but that users would have the > power to create such a function themselves in the php code space. I have no > clue how though...
Well my code has nothing to do with filtering. It's all about retrieving a default value if one is not set in response to the poster to which I replied. But yes, I was hasty with it in my eternal lack of wisdom, and of course forgot about scalars. For the record, I am indeed in favour of something that allows the choice of a value from a series of values for which some may not be set-- without the generation of not set warnings :) On that note, how comes there's a $GLOBAL array and not a $LOCAL array for vars declared in the immediate scope :) Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Sven Fuchs

21 years ago
Why isn't is possible in userland? Is there any problem with using this? function ifsetor(&$var, $default = null) { return isset($var) ? $var : $default; } echo ifsetor($a, 'foo'); echo $a, $b; echo ifsetor($a, 'foo'); echo isset($a) ? 'is set' : 'not set'; expected result: foo Notice: Undefined variable: a in [...] Notice: Undefined variable: b in [...] foo not set actual result: foo Notice: Undefined variable: b in [...] foo not set php does not issue a notice on using $a after having called ifsetor() once. But further calls to isset() and ifsetor() keep returning the expected results. I'd assume, the missing notice is rather a bug than a feature. So ifsetor() is possible in userland.
-- Sven

Ron Korving

21 years ago
No, ifsetor() is not possible in user land, because it generates notices, and a php core function ifsetor() would not generate notices. That's really the way it has to be. Ron "Sven Fuchs" <svenfuchs@artweb-design.de> wrote in message news:177634065.20050613225603@artweb-design.de...
> Why isn't is possible in userland? Is there any problem with using > this? > > function ifsetor(&$var, $default = null) { > return isset($var) ? $var : $default; > } > > echo ifsetor($a, 'foo'); > echo $a, $b; > echo ifsetor($a, 'foo'); > echo isset($a) ? 'is set' : 'not set'; > > expected result: > > foo > Notice: Undefined variable: a in [...] > Notice: Undefined variable: b in [...] > foo > not set > > actual result: > > foo > Notice: Undefined variable: b in [...] > foo > not set > > php does not issue a notice on using $a after having called ifsetor() > once. But further calls to isset() and ifsetor() keep returning the > expected results. > > I'd assume, the missing notice is rather a bug than a feature. So > ifsetor() is possible in userland. > > -- > Sven > > > > If it were possible at all to make a function accept unset variables
without
> > generating a notice, I think ifsetor() shouldn't even be implemented.
People
> > could then have the freedom to create such functions themselves. But > > unfortunately, it doesn't seem to be possible, unless you'd suppress
every
> > function call with a @, which I don't think is the way to go in this
case.
> > > So if it would be possible somehow to create your own isset()-like
functions
> > in PHP-code, I'd say implement something that would make that possible,
and
> > ingore the whole ifsetor() discussion from that moment on. People would
be
> > free to write whatever function they'd prefer. > > > Ron > > > > ""Sara Golemon"" <pollita@php.net> wrote in message > > news:38.CE.21296.BFD78A24@pb1.pair.com... > >> > > What about ifsetor for 5.1 ? > >> > > >> > Would anybody be interested in a parameter for ifsetor() that would > > treat > >> > isset() as !empty() or an alternative function that achieves this? I > > know > >> > I'd love to see that. I use empty() a lot more than isset(). > >> > > >> In the interrest of KISS, I'd leave the emptiness concept out of the > >> picture. Unlike isset-ness, an emptiness coalesce *can* be done in > >> userspace: > >> > >> function firstNotEmpty() { > >> $vars = func_get_args(); > >> foreach($vars as $var) > >> if (!empty($var)) return $var; > >> return NULL; > >> } > >> > >> There's enough....contention over the undeniably useful and > >> not-implementable-in-userspace parts of this thread that it's not worth > >> muddling it up with things that are a simple matter to do in userspace. > > It > >> doesn't matter that notempty() and ifsetor() could easily be
implemented

Sebastian Mendel

21 years ago
Ron Korving wrote:
>> function ifsetor(&$var, $default = null) { >> return isset($var) ? $var : $default; >> } >> >> echo ifsetor($a, 'foo'); >> echo $a, $b; >> echo ifsetor($a, 'foo'); >> echo isset($a) ? 'is set' : 'not set'; >> >> expected result: >> >> foo >> Notice: Undefined variable: a in [...] >> Notice: Undefined variable: b in [...] >> foo >> not set >> >> actual result: >> >> foo >> Notice: Undefined variable: b in [...] >> foo >> not set > > No, ifsetor() is not possible in user land, because it generates notices, > and a php core function ifsetor() would not generate notices. That's really > the way it has to be.
i see no notice produced by this ifsetor()
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Ron Korving

21 years ago
Hmm, you're right.. so the reference "&" already takes care of this... Well, then I don't see the point of the whole ifsetor() discussions... people can implement this themselves. Ron "Sebastian Mendel" <lists@sebastianmendel.de> wrote in message news:49.34.20931.46FDEA24@pb1.pair.com...
> Ron Korving wrote: > > >> function ifsetor(&$var, $default = null) { > >> return isset($var) ? $var : $default; > >> } > >> > >> echo ifsetor($a, 'foo'); > >> echo $a, $b; > >> echo ifsetor($a, 'foo'); > >> echo isset($a) ? 'is set' : 'not set'; > >> > >> expected result: > >> > >> foo > >> Notice: Undefined variable: a in [...] > >> Notice: Undefined variable: b in [...] > >> foo > >> not set > >> > >> actual result: > >> > >> foo > >> Notice: Undefined variable: b in [...] > >> foo > >> not set > > > > No, ifsetor() is not possible in user land, because it generates
notices,
> > and a php core function ifsetor() would not generate notices. That's
really

Zeev Suraski

21 years ago
At 16:54 14/06/2005, Sebastian Mendel wrote:
>Ron Korving wrote: > > >> function ifsetor(&$var, $default = null) { > >> return isset($var) ? $var : $default; > >> } > >> > >> echo ifsetor($a, 'foo'); > >> echo $a, $b; > >> echo ifsetor($a, 'foo'); > >> echo isset($a) ? 'is set' : 'not set'; > >> > >> expected result: > >> > >> foo > >> Notice: Undefined variable: a in [...] > >> Notice: Undefined variable: b in [...] > >> foo > >> not set > >> > >> actual result: > >> > >> foo > >> Notice: Undefined variable: b in [...] > >> foo > >> not set > > > > No, ifsetor() is not possible in user land, because it generates notices, > > and a php core function ifsetor() would not generate notices. That's really > > the way it has to be. > >i see no notice produced by this ifsetor()
One is not supposed to be emitted either, variables passed by reference don't generate notices regardless of whether they exist or not, to allow returning data through them. This implementation of issetor() actually works fine, except it does pollute the symbol tables with empty variables ($a and $b in this examples are created, as nulls). Zeev

Ron Korving

21 years ago
Hi Zeev, You're absolutely right.. How awful of me that I didn't see this coming. Honestly, what's the point of having an ifsetor() in PHP, when people can obviously write it themselves? Everybody wants a slighty different implementation of an ifsetor(), ifnotemptyor(), coalesce(), etc... Why are people wasting their breath on this? I figured it would be a good addition to PHP at first, but seeing as everyone could write this in PHP themselves, I really don't get the point. Maybe it's the case that a lot of pro-ifsetor() people, are unaware (like I was) of the fact that one really could implement a decent ifsetor() themselves? Ron "Zeev Suraski" <zeev@zend.com> wrote in message news:5.1.0.14.2.20050614165106.02a01c80@localhost...

Sven Fuchs

21 years ago
> This implementation of issetor() actually works fine, except it does > pollute the symbol tables with empty variables ($a and $b in this > examples are created, as nulls).
What are the consequences of polluting the symbol tables this way? Should this issetor() be considered a "bad practice", probably for medium to large scale applications?
-- Sven

Ron Korving

21 years ago
Personally, I doubt this is a problem.. I mean, how many ifsetor() variables are we talking here? You call the function, so therefor the variable could be set, otherwise you wouldn't be checking for it. In the case it was set, it would've been in the symbol table anyway. Ron "Sven Fuchs" <svenfuchs@artweb-design.de> wrote in message news:344317232.20050614161045@artweb-design.de...

Ron Korving

21 years ago
Personally, I doubt this is a problem.. I mean, how many ifsetor() variables are we talking here? You call the function, so therefor the variable could be set, otherwise you wouldn't be checking for it. In the case it was set, it would've been in the symbol table anyway. Ron "Sven Fuchs" <svenfuchs@artweb-design.de> wrote in message news:344317232.20050614161045@artweb-design.de...

Zeev Suraski

21 years ago
At 17:10 14/06/2005, Sven Fuchs wrote:
> > This implementation of issetor() actually works fine, except it does > > pollute the symbol tables with empty variables ($a and $b in this > > examples are created, as nulls). > >What are the consequences of polluting the symbol tables this way?
Well, it will increase memory usage, but unless you're dealing with a huge amount of variables, that should be pretty negligible. It might also not work properly in certain cases, because PHP isn't truly capable of differentiating between variables those empty variables and real variables that contain nulls. For example, function ifsetor(&$x) { } ifsetor($foo); print $foo; will not generate a notice on a non existing variable, but will emit it if the call to ifsetor() is removed.
>Should this issetor() be considered a "bad practice", probably for >medium to large scale applications?
I think that a more practical implementation may be something like: function ifsetor(&$x, $default=null) { if (!isset($x)) { $x = $default; } return $x; } i.e., assign the variable with the default value if it doesn't yet exist. I think it usually desirable (not always, naturally) and since we want the variable to exist in this case, there's no pollution issue. I fully agree with everyone else that wondered why we're discussing this. People can implement this on their own, the way they want it, with an assignment or without it, using empty() or isset(), etc. Zeev

Ron Korving

21 years ago
There is one case though, which can still not be implemented (probably?) by users, and that's a coalesce function, since that would require fetching values by using func_get_args(), which doesn't return references. So the only way I could imagine implementing such coalesce() function would be like this: function coalesce(&$a=null, &$b=null, &$c=null, &$d=null, &$e=null) { if (isset($a)) return $a; if (isset($b)) return $b; if (isset($c)) return $c; if (isset($d)) return $d; return $e; } Which I think is pretty hideous. But I can absolutely live with a lack of coalesce() since that function wouldn't be as extensively used as ifsetor(). As far as I'm concerned on ifsetor() though: -18927. But then again, who am I to make such a statement? :) Ron "Zeev Suraski" <zeev@zend.com> wrote in message news:5.1.0.14.2.20050614171838.051169a0@localhost... ....

Sven Fuchs

21 years ago
Great. Thanks a lot for the improvement.
-- Sven

Marcus Boerger

21 years ago
Hello Zeev, though the idea is nice and & does what we want here to a certain level it still doesn't allow to implement ifsetor() or coalesce() or any other flavor described here as proved by the following snippet: marcus@zaphod ~ $ php -r 'function ifsetor(&$a, $def=false) { return isset($a) ? $a : $def; } $a= array(); $x = ifsetor($a[12][34], 42); var_dump($x); var_dump($a);' int(42) array(1) { [12]=> array(1) { [34]=> NULL } } I expect $a to be untouched of course. May this is another reason to implement my const pass signature info. But then it might not be implementable for this specific problem. best regards marcus Tuesday, June 14, 2005, 4:26:44 PM, you wrote:
> At 17:10 14/06/2005, Sven Fuchs wrote: >> > This implementation of issetor() actually works fine, except it does >> > pollute the symbol tables with empty variables ($a and $b in this >> > examples are created, as nulls). >> >>What are the consequences of polluting the symbol tables this way?
> Well, it will increase memory usage, but unless you're dealing with a huge > amount of variables, that should be pretty negligible. It might also not > work properly in certain cases, because PHP isn't truly capable of > differentiating between variables those empty variables and real variables > that contain nulls. For example,
> function ifsetor(&$x) { } > ifsetor($foo); > print $foo;
> will not generate a notice on a non existing variable, but will emit it if > the call to ifsetor() is removed.
>>Should this issetor() be considered a "bad practice", probably for >>medium to large scale applications?
> I think that a more practical implementation may be something like:
> function ifsetor(&$x, $default=null) > { > if (!isset($x)) { > $x = $default; > } > return $x; > }
> i.e., assign the variable with the default value if it doesn't yet > exist. I think it usually desirable (not always, naturally) and since we > want the variable to exist in this case, there's no pollution issue.
> I fully agree with everyone else that wondered why we're discussing > this. People can implement this on their own, the way they want it, with > an assignment or without it, using empty() or isset(), etc.
> Zeev
-- Best regards, Marcus mailto:mail@marcus-boerger.de

Zeev Suraski

21 years ago
Marcus, If you read what I said in my emails on this topic, it's clear that I know that this is the case. As I said, this approach has the side effect of creating an empty placeholder if the variable to be checked doesn't exist. I also said that I think it would usually make more sense to simply assign the variable with the wanted value, instead of just returning that value, so that you don't have to clutter your code with ifsetor()'s or whatever each coder ends up calling this (sometimes it may not be desirable, obviously, but I assume it would be more often than not). At the end of the day, this is really a nuance. Fact is that it's possible to implement ifsetor() functionality today in userland. We cannot go around implementing a new construct for every possible thing that someone might need. This should be implemented in userland, even if it has a small side effect. It gives you the full power of doing whatever you want, instead of being limited to what a low level construct does. Zeev At 20:04 16/06/2005, Marcus Boerger wrote:

Andi Gutmans

21 years ago
Hi, Finally catching up with all the million comments. Definitely a way to get distracted from real work :) I don't want to get distracted from what I consider should be the main objective and bigger issues than yes to one or another feature. We should get PDO, new execution engine and some other changes out to the public. We need to fold in the Unicode changes into public CVS before we have a maintenance nightmare. We can't manage more than two PHP 5 branches at once. It'll be unmaintainable and tough. I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting some very much needed feedback from the public for HEAD. After talking to Andrei & Rasmus, I think it becomes clear that we should aim to RC 5.1 in the beginning of July so that we can close the 5.0.x branch and merge Unicode into HEAD. There will hopefully then be a quick development cycle for upgrading a lot of functions for Unicode support, and in addition we could address some features like goto, and other improvements which are required. Releasing 5.1 doesn't mean 5.5 or 6.0 (whatever we call the Unicode version) couldn't be released this year. I'm sure Andrei would love that :) (so would I, and incidentally my original name is Andrei too). It's for the benefit of all to make progress and not slow the release cycle to a halt, especially for people who are looking forward to the "major" features. We have some great stuff coming and it'll go bad if we don't move the major pieces along. Andi P.S. - Anyway, from looking over the thread it definitely seems like 100 people have had 101 different ideas for ifsetor(). Just strengthens my point of doing it yourself in code. As far as goto is concerned, I pointed out some technical issues (Stas mentioned some) as far as the implementation is concerned back when Sara did her patch. I don't object to having a strict, static implementation of goto when we get a clean implementation. Actually I might even take it upon myself to look for a solution. It should go into the Unicode version. It's not high priority and I'm sure PHP users around the globe will survive without it for a while.

Andrei Zmievski

21 years ago
I wholeheartedly agree with Andi: we already have a very full-featured release with 5.1 and we should have a beta out as soon as possible in order to start getting user feedback. The fact that ifsetor() and goto have generated such large discussions shows that we are not in agreement on how or if they would be implemented. I am sure these discussions could continue for a long time, but we do need to keep in mind that Unicode support will also require a lot of work from extension authors as well as the scrutiny by many eyeballs so that we can catch all the corner cases and bugs. Let's get the ball rolling. -Andrei P.S. I thought Andi was Zeev's double, not mine?

George Schlossnagle

21 years ago
On Jun 9, 2005, at 6:51 PM, Andi Gutmans wrote:
> Hi, > > Finally catching up with all the million comments. Definitely a way > to get distracted from real work :) > > I don't want to get distracted from what I consider should be the > main objective and bigger issues than yes to one or another feature. > We should get PDO, new execution engine and some other changes out > to the public. > We need to fold in the Unicode changes into public CVS before we > have a maintenance nightmare. We can't manage more than two PHP 5 > branches at once. It'll be unmaintainable and tough. > > I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start > getting some very much needed feedback from the public for HEAD. > > After talking to Andrei & Rasmus, I think it becomes clear that we > should aim to RC 5.1 in the beginning of July so that we can close > the 5.0.x branch and merge Unicode into HEAD. There will hopefully > then be a quick development cycle for upgrading a lot of functions > for Unicode support, and in addition we could address some features > like goto, and other improvements which are required. Releasing 5.1 > doesn't mean 5.5 or 6.0 (whatever we call the Unicode version) > couldn't be released this year. > I'm sure Andrei would love that :) (so would I, and incidentally my > original name is Andrei too). > > It's for the benefit of all to make progress and not slow the > release cycle to a halt, especially for people who are looking > forward to the "major" features. We have some great stuff coming > and it'll go bad if we don't move the major pieces along.
I think this is an excellent idea. All of the features being debated hotly now are extremely minor compared to good unicode support, and given the broad effect of that change, getting it into HEAD and thus into mainstream development usage would be a really good thing. George

Rasmus Lerdorf

21 years ago
George Schlossnagle wrote:
>> It's for the benefit of all to make progress and not slow the release >> cycle to a halt, especially for people who are looking forward to the >> "major" features. We have some great stuff coming and it'll go bad if >> we don't move the major pieces along. > > I think this is an excellent idea. All of the features being debated > hotly now are extremely minor compared to good unicode support, and > given the broad effect of that change, getting it into HEAD and thus > into mainstream development usage would be a really good thing.
Yes, I am pretty sure the current discussions will pale in comparison to the chaos that will be created when the Unicode stuff goes into HEAD! ;) We need to get this code in front of more eyes as soon as possible so people can start to share this pain. -Rasmus

Derick Rethans

21 years ago
On Thu, 9 Jun 2005, Andi Gutmans wrote:
> I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting some > very much needed feedback from the public for HEAD.
I'll put the date time stuff in today then. (Before you wake up probably :). This will only replace strtotime() , we can discuss what else we add later - not? Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Pierre-Alain Joye

21 years ago
On Fri, 10 Jun 2005 09:07:26 +0200 (CEST) derick@php.net (Derick Rethans) wrote:
> On Thu, 9 Jun 2005, Andi Gutmans wrote: > > > I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start > > getting some very much needed feedback from the public for HEAD. > > I'll put the date time stuff in today then. (Before you wake up > probably :). This will only replace strtotime() , we can discuss > what else we add later - not?
Indeed, I need some time after your commits, to update pecl/date and see where is the place to put it. That said, tomorrow is not end of next week, any reason to change the planning? If yes, I should have beged Derick much more this week to get this stuff in.... Regards, --Pierre

Wez Furlong

21 years ago
I was hoping to get a little bit more PDO hacking done (see last nights commits :) before the beta. I'm closing on my new house today and moving this weekend. I don't really want to delay the beta, but can we push it back until next weekend? --Wez. On 6/10/05, Derick Rethans <derick@php.net> wrote:

Wez Furlong

21 years ago
Well, we shipped 5.1 beta with a critical shutdown problem in PDO, that would have been caught if we'd just waited one more day. Andi: just one more week wasn't too much to ask, especially since several of our core guys wanted that extra time. Just because it's beta, doesn't mean that we shouldn't have some QA; the sensible thing to do would have been to tarball it and have us test it internally before announcing the release. That way, more than one person could have spotted my late-night coding error; now we're going to get a slew of bug reports about it--I hope you can attend to those, because I certainly don't have the time for it now. --Wez. (yes, somewhat pissed because this was totally avoidable) On 6/10/05, Wez Furlong <kingwez@gmail.com> wrote:

Andi Gutmans

21 years ago
Hi Wez, My understanding was that your focus was on the SQLite UDF stuff. Last time I asked you said PDO was solid and I didn't realize you knew of a PDO bug that was critical. Regarding notice, I gave a weeks notice for Beta 1... People wanted additional time for features not for bug fixes. That is always the case. But anyway, no sweat. I posted it on a Friday on purpose so that it would be a more gradual roll out. This gives the release less exposure. Also I marked it not suitable for production use. I will roll Beta 2, to make sure that what we have out there is in working order. Is the CVS ready for it? I can post the tarball afterwards if you want to dev before I put them on php.net. Andi At 10:55 AM 6/11/2005 -0400, Wez Furlong wrote:

Andi Gutmans

21 years ago
Hi Wez and all, I built Beta 2 with the latest CVS which appears to have Wez's fixes. Please check it out and let me know if it resolves the critical problem and can be posted. http://snaps.php.net/~andi/php-5.1.0b2.tar.bz2 http://snaps.php.net/~andi/php-5.1.0b2.tar.gz Andi

Derick Rethans

21 years ago
On Sat, 11 Jun 2005, Andi Gutmans wrote:
> Hi Wez and all, > > I built Beta 2 with the latest CVS which appears to have Wez's fixes. Please > check it out and let me know if it resolves the critical problem and can be > posted.
Very nice Andi. I asked yesterday for one or two days, then you put out beta1 one followed by beta 2 a day later. That does not make a single bit of sense. besides that, the NEWS file is still broken, it misses the changes from 5.0.4 to 5.0.5-dev. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Jani Taskinen

21 years ago
On Sat, 11 Jun 2005, Derick Rethans wrote:
> On Sat, 11 Jun 2005, Andi Gutmans wrote: > >> Hi Wez and all, >> >> I built Beta 2 with the latest CVS which appears to have Wez's fixes. Please >> check it out and let me know if it resolves the critical problem and can be >> posted. > > Very nice Andi. I asked yesterday for one or two days, then you put out > beta1 one followed by beta 2 a day later. That does not make a single > bit of sense. > > besides that, the NEWS file is still broken, it misses the changes from > 5.0.4 to 5.0.5-dev.
Instead of adding to this nagging I went and added those entries myself. Now get your finger out of your ass, stop whining and actually commit the ext/date stuff! --Jani

Andi Gutmans

21 years ago
At 07:41 PM 6/11/2005 +0200, Derick Rethans wrote:
>On Sat, 11 Jun 2005, Andi Gutmans wrote: > > > Hi Wez and all, > > > > I built Beta 2 with the latest CVS which appears to have Wez's fixes. > Please > > check it out and let me know if it resolves the critical problem and can be > > posted. > >Very nice Andi. I asked yesterday for one or two days, then you put out >beta1 one followed by beta 2 a day later. That does not make a single >bit of sense.
It makes a lot of sense. PDO and the new Engine changes require quite a bit of exposure to be sure we can release them. On the other hand, we have Unicode work that we should merge within the next few weeks so that we can all work on it and have maintainable trees. I'll be happy to discuss this with you further in MSN later on today. Regarding the Date stuff. You've been saying for months that it'll be ready when it's ready and that I shouldn't wait. Before I released Beta 1 you said that you'll merge the important parts after Beta 1, which IMO is OK as what really needs testing right now is PDO and ZEII. Maybe there's something I missed. You have to understand, that we can't have the same situation we have had in the past few months where every time we talk about a beta, it requires another week. The recursion has to stop at some point and this has always been the case in the past; especially for a beta. It's unfortunate that there was a critical bug in PDO but that was due to a misunderstanding between Wez and myself. I thought that he was talking about his recent SQLite UDF work and not a more critical bug. On a side note, I'm not even sure how critical it is, for a beta which is marked not for production use, as it probably only happens with transactional DBs where the transaction is stopped in the middle. But I'll discuss this with Wez to understand better. In any case, it's not like the world came to an end. It's fixable and we've had situations in the past where we had to follow-up with a release close to another release.
>besides that, the NEWS file is still broken, it misses the changes from >5.0.4 to 5.0.5-dev.
Still broken? First time I see you pointing it out but I might have missed an email from you. I'll fix it when I also hear back from Wez and will re-roll. Andi

Pierre-Alain Joye

21 years ago
On Sat, 11 Jun 2005 11:06:48 -0700 andi@zend.com (Andi Gutmans) wrote:
> At 07:41 PM 6/11/2005 +0200, Derick Rethans wrote: > >On Sat, 11 Jun 2005, Andi Gutmans wrote: > > > > > Hi Wez and all, > > > > > > I built Beta 2 with the latest CVS which appears to have > > > Wez's fixes. > > Please > > > check it out and let me know if it resolves the critical > > > problem and can be posted. > > > >Very nice Andi. I asked yesterday for one or two days, then you > >put out beta1 one followed by beta 2 a day later. That does not > >make a single bit of sense. > > It makes a lot of sense. PDO and the new Engine changes require > quite a bit of exposure to be sure we can release them. On the > other hand, we have Unicode work that we should merge within the > next few weeks so that we can all work on it and have > maintainable trees. I'll be happy to discuss this with you > further in MSN later on today. > > Regarding the Date stuff. You've been saying for months that > it'll be ready when it's ready and that I shouldn't wait Befor > I released Beta 1 you said that you'll merge the importan part > after Beta 1, which IMO is OK as what really needs testin righ > now is PDO and ZEII. Maybe there's something I missed.y
Regarding the date stuffs, as I told in my last post, I am ready. Derick asked for a couple of days delay, so did Wez too. The most important problem here is not whether or not we were ready but the way PHP releases are managed (or better said not managed at all). This time, I'm lucky enough to have some other developers having troubles. This is not your fault or anyone else fault. this is a communication problem. PHP is getting bigger, more developers are active than ever before. How can you ask so many people to be ready by tomorrow as you asked a few days ago to be ready end of next week? What is the reason for such a change? As a sidenote, with so many developers, I can say that tomorrow does not exit in a release world, next week does sometimes, end of the month being the best choice. I would like to see you respecting your original dead line, and that's the end of next week. I, as some many other, have to plan my work, so I did in coordination with Derick for our date tasks. Why should I now even try to be in time if the given deadlines can be changed in such random ways? I'm not blaming you directly, you may not have the choices. I'm blaming all of us to do not communicate and to do not organize a bit our team work. Best regards, --Pierre

Andi Gutmans

21 years ago
Hi Pierre, There was definitely a communication problem because on June 3rd, I said I'd like to roll next week, hopefully Thursday. I rolled on Friday 8 days later. So I definitely did try and give a weeks heads-up and also synced with some people individually about what could make it in and what not. In any case, I'll make sure to try and improve that from now on. You must note though that it's impossible to have everything synced and it will never happen that everyone feels they got all their changes in, or we'd never ever release. The main problem here was a misunderstanding where I misunderstood Wez' request regarding PDO. Anyway, in my opinion not much harm has been done. I will sync up with Wez & Derick to release Beta 2. I believe there is very little delta. It is a beta after all for a good reason. Andi At 08:53 PM 6/11/2005 +0200, Pierre-Alain Joye wrote:

Andreas Korthaus

21 years ago
Hi! Andi Gutmans wrote:
> I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start > getting some very much needed feedback from the public for HEAD.
Will pecl_http be included? (AFAIR something like that has been discussed earlier this year on this list) I'm asking because it's such a great (and secure) alternative to allow_url_fopen.
> It's for the benefit of all to make progress and not slow the release > cycle to a halt, especially for people who are looking forward to the > "major" features. We have some great stuff coming and it'll go bad if > we don't move the major pieces along.
Absolutely! I'm really looking forward to all these great, new features! (I have scripts running 40-50% faster with 5.1-dev; PDO, xmlreader, pecl_http work great...) kind regards Andreas

Andreas Korthaus

21 years ago
Hi! Andi Gutmans wrote:
> I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting > some very much needed feedback from the public for HEAD.
Will pecl_http be included? (AFAIR something like that has been discussed earlier this year on this list) I'm asking because it's such a great (and secure) alternative to allow_url_fopen.
> It's for the benefit of all to make progress and not slow the release > cycle to a halt, especially for people who are looking forward to the > "major" features. We have some great stuff coming and it'll go bad if we > don't move the major pieces along.
Absolutely! I'm really looking forward to all these great, new features! (I have scripts running 40-50% faster with 5.1-dev; PDO, xmlreader, pecl_http work great...) kind regards Andreas

Derick Rethans

21 years ago
On Fri, 10 Jun 2005, Andreas Korthaus wrote:
> Andi Gutmans wrote: > > > I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting some > > very much needed feedback from the public for HEAD. > > Will pecl_http be included? > (AFAIR something like that has been discussed earlier this year on this list)
We have the policy of not adding more very specialized extensions to the PHP core distribution - those extensions should live in PECL. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Andreas Korthaus

21 years ago
Derick Rethans wrote:
> On Fri, 10 Jun 2005, Andreas Korthaus wrote: > >>Will pecl_http be included? >>(AFAIR something like that has been discussed earlier this year on this list) > > > We have the policy of not adding more very specialized extensions to the > PHP core distribution - those extensions should live in PECL.
Yes, that makes a lot of sense. I have seen that many core-Extensions have been moved to PECL, and I think is's the right way. But in php-core you have many similarly specialized Extensions, such as ftp, imap, snmp... And in my opinion HTTP is used more often than those core-Extensions. I'm reading and writing a lot in php-related forums and I do not hear people using those core-Extensions very often. But nearly every day I recommend people using things like PEAR::HTTP_Request (which is not easy to install in shared hosting, the alternative is writing your own userspace function/class using fsockopen...), or explain why "include($_GET['site']);" is not a good idea... I think pecl_http is not more specialized than most other core-Extensions, but from my (users) point of view it is a very valuable extension for most users. If it lives in PECL, I think must users will never use it. But it's not my decision ;-) best regards Andreas

Michael Wallner

21 years ago
Hi Andreas Korthaus, you wrote:
> Will pecl_http be included? (AFAIR something like that has been > discussed earlier this year on this list)
Hm, I must have missed that... Anyway it's still far away from stable - just compare the count of tests against the amount of functionality provided. Regards,
-- Michael - < mike(@)php.net >

Andreas Korthaus

21 years ago
Michael Wallner wrote:
>>Will pecl_http be included? (AFAIR something like that has been >>discussed earlier this year on this list) > > Hm, I must have missed that...
I cannot find it anymore, perhaps it only has been suggested...
> Anyway it's still far away from stable - just compare the > count of tests against the amount of functionality provided.
OK, I wrote some small scripts and it worked quite nice. Very good work, it's (or will be...) a really useful extension! I hope it will be added to php-core some day ;-) best regards Andreas

Michael Wallner

21 years ago
Hi Andreas Korthaus, you wrote:
> Michael Wallner wrote: >> Anyway it's still far away from stable - just compare the >> count of tests against the amount of functionality provided. > > OK, I wrote some small scripts and it worked quite nice. Very good work, > it's (or will be...) a really useful extension!
Thanks a lot, if you've got suggestions or complaints... or even want to contribute code, tests etc. -- you know :)
> I hope it will be added to php-core some day ;-)
Well, don't expect it... ;) Regards,
-- Michael - < mike(@)php.net >

Marcus Boerger

21 years ago
Hello Andi, Saturday, June 4, 2005, 7:58:13 AM, you wrote:
> Hey,
> There have been a lot of questions and discussion regarding status of PHP 5.1. > In the past few weeks, many have been fixing lots of bugs and PDO seems to > have reached a pretty stable state. > In parallel, a lot of work has been done offline by Andrei, Dmitry and > others, to enable Unicode support in PHP and the Zend Engine. > I believe it is time now to move 5.1 forward at a much faster pace. I'd > like to roll a beta of it towards the end of next week such as Thursday > (giving a chance for some last minute fixes), and then hopefully RC within > a week or two. > Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make HEAD the > Unicode development stream (merging Unicode changes into HEAD).
> Hopefully, by going at this pace, we can have a pretty decent Unicode > version of PHP out there within a few months; and have PDO out there almost > immediately.
There are a few things i'd like to address before: 1) return by reference at c-level. This is already taken care of by dmitry who is currently working on a better patch than mine. However i need this to finalizy ArrayAccess interface. And i need a bit of a time to experiment with the result and maybe others want to give their input as well. At the moment the problem is that it cannot deal with references at all but there is already coe out with 5.0 that used that issue. So here is just somewhat work and testing needed. 2) PHP is all about the putting out text so nearly all objects created in PHP are meant to put something onto the generated pages. Thus i think i am not alone to suggest we put back the magic __toString function in place as we said when we dropped it's support from 5.0. Also it is very hard to explain why "echo $a . $obj" and "echo $a, $obj" output different things when one is an object. Both is pretty much against the spirit of PHP - easiness isn't it? 3) Is 5.1 coming out without filtering? 4) I still want the ifsetor operator since it is very helpfull and again simplifies a lot of things. 5) tons of other stuff i menationed offline and in public - since i lost the energy in tracking all that issues i guess the work and time in those wasn't worse the effort and they can wait anyway :-) best regards marcus

Johannes Schlueter

21 years ago
Hi, On Sunday 05 June 2005 19:18, Marcus Boerger wrote:
> 2) PHP is all about the putting out text so nearly all objects created in > PHP are meant to put something onto the generated pages. Thus i think i am > not alone to suggest we put back the magic __toString function in place as > we said when we dropped it's support from 5.0. Also it is very hard to > explain why "echo $a . $obj" and "echo $a, $obj" output different things > when one is an object. Both is pretty much against the spirit of PHP - > easiness isn't it?
Especially with "echo $a . $obj" and "echo $a, $obj" it's really annoying. Many people are concating when printing stuff and it's hard to explain why the results differ...
> 4) I still want the ifsetor operator since it is very helpfull and again > simplifies a lot of things.
+10
> 5) tons of other stuff i menationed offline and in public - since i lost > the energy in tracking all that issues i guess the work and time in those > wasn't worse the effort and they can wait anyway :-)
Is there progress with the new date stuff? I'd really like to have dates before 1970. johannes
-- Johannes Schlüter Mayflower GmbH / ThinkPHP http://thinkphp.de http://blog.thinkphp.de

Derick Rethans

21 years ago
On Sun, 5 Jun 2005, Johannes Schlueter wrote:
> Is there progress with the new date stuff? I'd really like to have dates > before 1970.
Should go in this week. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Pierre-Alain Joye

21 years ago
On Sun, 5 Jun 2005 22:29:13 +0200 (CEST) derick@php.net (Derick Rethans) wrote:
> On Sun, 5 Jun 2005, Johannes Schlueter wrote: > > > Is there progress with the new date stuff? I'd really like to > > have dates before 1970. > > Should go in this week.
Finally :) If Derick's TZ and new strtotime go in this week, then pecl/date will be updated accordingly and ready to go to ext as well. If not, it will be ready with its own TZ support in the wait of Derick's one. Again in pecl, xmlwriter is be ready as well, I only have the OO interface to commit. Regards, --Pierre

David Zülke

21 years ago
How about bundling PIMP with 5.1? ;o) - David

Pierre-Alain Joye

21 years ago
On Sun, 5 Jun 2005 23:57:40 +0200 dz@bitxtender.com (David Zülke) wrote:
> How about bundling PIMP with 5.1? ;o)
Pimp as php ext is not on my top priority :) However it should be available on its own repository later this summer. That said, for the current GD, I'm working to sync the Boutell and ours (in both direction), should be commited in the next days. Regards, --Pierre

Steph

21 years ago
Animated .gif support? :) ----- Original Message ----- From: "Pierre-Alain Joye" <pierre@dotgeek.org> To: "David Zülke" <dz@bitxtender.com> Cc: <internals@lists.php.net> Sent: Monday, June 06, 2005 1:02 AM Subject: Re: [PHP-DEV] PHP 5.1 On Sun, 5 Jun 2005 23:57:40 +0200 dz@bitxtender.com (David Zülke) wrote:
> How about bundling PIMP with 5.1? ;o)
Pimp as php ext is not on my top priority :) However it should be available on its own repository later this summer. That said, for the current GD, I'm working to sync the Boutell and ours (in both direction), should be commited in the next days. Regards, --Pierre
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Lukas Smith

21 years ago
Marcus Boerger wrote:
> 4) I still want the ifsetor operator since it is very helpfull and again > simplifies a lot of things.
+1 +1 for goto as well regards, Lukas

Marcus Boerger

21 years ago
Hello Andi, i forgot to mention one major problem. The current implementation of extension dependency requires gnu-awk. If another awk implementation is being used to generate php then the result is an immediate segfaulting php binary. We should either make gawk checked by configure or rewrite the exetension dependency by tables in the module struct so a dependent extension doesn't get MINITed before its dependencies are initialized. Probably we can go require way for 5.1 and have the other one done for 5.2. Sunday, June 5, 2005, 7:18:26 PM, you wrote:
> Hello Andi,
> Saturday, June 4, 2005, 7:58:13 AM, you wrote:
>> Hey,
>> There have been a lot of questions and discussion regarding status of PHP 5.1. >> In the past few weeks, many have been fixing lots of bugs and PDO seems to >> have reached a pretty stable state. >> In parallel, a lot of work has been done offline by Andrei, Dmitry and >> others, to enable Unicode support in PHP and the Zend Engine. >> I believe it is time now to move 5.1 forward at a much faster pace. I'd >> like to roll a beta of it towards the end of next week such as Thursday >> (giving a chance for some last minute fixes), and then hopefully RC within >> a week or two. >> Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make HEAD the >> Unicode development stream (merging Unicode changes into HEAD).
>> Hopefully, by going at this pace, we can have a pretty decent Unicode >> version of PHP out there within a few months; and have PDO out there almost >> immediately.
> There are a few things i'd like to address before:
> 1) return by reference at c-level. This is already taken care of by dmitry > who is currently working on a better patch than mine. However i need this > to finalizy ArrayAccess interface. And i need a bit of a time to experiment > with the result and maybe others want to give their input as well. At the > moment the problem is that it cannot deal with references at all but there > is already coe out with 5.0 that used that issue. So here is just somewhat > work and testing needed.
> 2) PHP is all about the putting out text so nearly all objects created in > PHP are meant to put something onto the generated pages. Thus i think i am > not alone to suggest we put back the magic __toString function in place as > we said when we dropped it's support from 5.0. Also it is very hard to > explain why "echo $a . $obj" and "echo $a, $obj" output different things > when one is an object. Both is pretty much against the spirit of PHP - > easiness isn't it?
> 3) Is 5.1 coming out without filtering?
> 4) I still want the ifsetor operator since it is very helpfull and again > simplifies a lot of things.
> 5) tons of other stuff i menationed offline and in public - since i lost > the energy in tracking all that issues i guess the work and time in those > wasn't worse the effort and they can wait anyway :-)
> best regards > marcus
-- Best regards, Marcus mailto:mail@marcus-boerger.de

Wez Furlong

21 years ago
I think the problem is only present if they have mawk installed under the name 'awk'. Magnus and I spent a fair bit if time trying things out with different awk implementations, as usual, with minimal feedback from anyone else, either in the internals community or outside of it. How about having someone with mawk tweak the script so that it *does* work? There is nothing in there that really requires a specific awk implementation, and gawk certainly isn't installed on systems such as Solaris, where the dependency script works just fine. So, if you have mawk, get your finger out. --Wez. On 6/8/05, Marcus Boerger <mail@marcus-boerger.de> wrote:

Andi Gutmans

21 years ago
At 07:18 PM 6/5/2005 +0200, Marcus Boerger wrote:
>There are a few things i'd like to address before: > >1) return by reference at c-level. This is already taken care of by dmitry >who is currently working on a better patch than mine. However i need this >to finalizy ArrayAccess interface. And i need a bit of a time to experiment >with the result and maybe others want to give their input as well. At the >moment the problem is that it cannot deal with references at all but there >is already coe out with 5.0 that used that issue. So here is just somewhat >work and testing needed.
I saw some work of Dmitry's on this issue. Will look what's happening with it.
>2) PHP is all about the putting out text so nearly all objects created in >PHP are meant to put something onto the generated pages. Thus i think i am >not alone to suggest we put back the magic __toString function in place as >we said when we dropped it's support from 5.0. Also it is very hard to >explain why "echo $a . $obj" and "echo $a, $obj" output different things >when one is an object. Both is pretty much against the spirit of PHP - >easiness isn't it?
I thought you were going to write a patch up. Did you look into it?
>3) Is 5.1 coming out without filtering?
Obviously not. I don't see anyone actively working on it. I am hoping to allocate resources to it in the near future but it'll come out when it comes out, especially as it's an extension. It might even live in PECL until everyone is happy with it. I want to try and work on an API proposal first because I believe the API is where the issue is and not the coding...
>4) I still want the ifsetor operator since it is very helpfull and again >simplifies a lot of things.
I don't think ifsetor() shortcut is a big deal nor needed in PHP. I've said it numerous times. Once we have a filtering API there will be even less times where it will be applicable. Write an extra 10 characters or so...
>5) tons of other stuff i menationed offline and in public - since i lost >the energy in tracking all that issues i guess the work and time in those >wasn't worse the effort and they can wait anyway :-)
Yes, many bugs have been fixed and issues have been addressed. Like always, there will always be open issues. It has been like this with every PHP release. Most important is to make sure that PHP 5.1 is only better and not worse than PHP 5.0, which I'm confident it is. And bringing PDO to the PHP community, and allowing for Unicode work to fold into PHP dev tree is the most important goal. Andi

Marcus Boerger

21 years ago
Hello Andi, Sunday, June 5, 2005, 9:13:52 PM, you wrote:
> At 07:18 PM 6/5/2005 +0200, Marcus Boerger wrote: >>2) PHP is all about the putting out text so nearly all objects created in >>PHP are meant to put something onto the generated pages. Thus i think i am >>not alone to suggest we put back the magic __toString function in place as >>we said when we dropped it's support from 5.0. Also it is very hard to >>explain why "echo $a . $obj" and "echo $a, $obj" output different things >>when one is an object. Both is pretty much against the spirit of PHP - >>easiness isn't it?
> I thought you were going to write a patch up. Did you look into it?
Sure but i lost track of all my patches. Maybe i should start a list that stores their review state so i can bug you more :-) Joke aside i forgot to do that so thanks for the reminder. You'll find it attached.
>>3) Is 5.1 coming out without filtering?
> Obviously not. (...). I want to try and work on an API proposal > first because I believe the API is where the issue is and not the coding...
Cool :-)
>>5) tons of other stuff i menationed offline and in public - since i lost >>the energy in tracking all that issues i guess the work and time in those >>wasn't worse the effort and they can wait anyway :-)
> Yes (...). Most important is to make sure that PHP 5.1 is only better and not > worse than PHP 5.0, which I'm confident it is. And bringing PDO to the PHP > community, and allowing for Unicode work to fold into PHP dev tree is the > most important goal.
It is already much faster and i heared many people claiming 5.0 was to slow. Also going for unicode seems very important. marcus

Rasmus Lerdorf

21 years ago
Andi Gutmans wrote:
> Obviously not. I don't see anyone actively working on it. I am hoping to > allocate resources to it in the near future but it'll come out when it > comes out, especially as it's an extension. It might even live in PECL > until everyone is happy with it. I want to try and work on an API > proposal first because I believe the API is where the issue is and not > the coding...
pecl/filter The framework for it is in place. I'll try to get some actual filters implemented this week. It's fine as a pecl extension for now. The hooks have been in place for a while, so it shouldn't hold up 5.1. -Rasmus

Jason Garber

21 years ago
Hello Andi, I have to strongly disagree with your ifsetor() comment. the use for ifsetor is in no way eliminated with filtering. I write very clean code and have taught all my developers to write very clean code. We run the latest stable PHP version with maximum error reporting. We do this so we can have more secure code with fewer logic errors. However, running in E_STRICT makes life rather miserable for simple things such as accessing any array key that may or may not have been included. I'm finding myself having the need for the ifsetor() construct in all areas of programming - not just in _POST or _GET. Even though you don't see yourself using it much, there are many developers on this list who DO see the use for it, and there are countless developers off this list who don't even know about it, but would find it useful for migrating to E_ALL | E_STRICT error reporting. If there was any way to accommodate this with userland PHP code, I would have already done it. However it is an engine level function that has to be added to the core of PHP. +ALot Thanks.
-- Best regards, Jason mailto:jason@ionzoft.com Sunday, June 5, 2005, 3:13:52 PM, you wrote: >>4) I still want the ifsetor operator since it is very helpfull and again >>simplifies a lot of things. AG> I don't think ifsetor() shortcut is a big deal nor needed in PHP. I've said AG> it numerous times. Once we have a filtering API there will be even less AG> times where it will be applicable. Write an extra 10 characters or so... AG> Andi

Sean Coates

21 years ago
Jason Garber wrote:
> If there was any way to accommodate this with userland PHP code, I > would have already done it. However it is an engine level function > that has to be added to the core of PHP.
For the record, I also find ifsetor useful, but what you want can be accomplished like this: $email = isset($_GET['email']) ? $_GET['email'] : 'no email address'; ifsetor would make this much nicer, but there /is/ a way to accomplish what you want in userland. S

Jason Garber

21 years ago
Hello Sean, I should have clarified this -- The following is how I do it all the time. It's just a bit longhanded for something that is done so often. $email = (isset($_GET['email']) ? $_GET['email'] : ''); It get's even messier when you want to get something like this: $value = (integer) (isset($myBigArray['SomeKey1']['SomeOtherKey']) ? $myBigArray['SomeKey1']['SomeOtherKey'] : 0); where $value = ifsetor($myBigArray['SomeKey1']['SomeOtherKey'], 0); is a bit cleaner. Thanks.
-- Best regards, Jason mailto:jason@ionzoft.com Monday, June 6, 2005, 1:22:11 PM, you wrote: SC> Jason Garber wrote: >> If there was any way to accommodate this with userland PHP code, I >> would have already done it. However it is an engine level function >> that has to be added to the core of PHP. SC> For the record, I also find ifsetor useful, but what you want can be SC> accomplished like this: SC> $email = isset($_GET['email']) ? $_GET['email'] : 'no email address'; SC> ifsetor would make this much nicer, but there /is/ a way to accomplish SC> what you want in userland. SC> S

Xuefer Tinys

21 years ago
(recall: eliminating warning is as important as dealing with errors. u can't figure out which warning is relative to the problem if there's too many noise warning.) all of u in -internals is expert. u might have forgot how ppl learn php. "simple" is the spirit of php, but is adding feature always make php complex? in the following example, it's actually much simple, it's not the problem we type how much letters it's 'how' we code, how the beginner will code. *** if u give the beginners "ifsetor", they will use it happily, not the "isset + ?:" one. u might say "hey, beginners should always learn not to be one". but i would say, no. there're many beginners who write many big programms(and bad), they even share it with others but don't even know he should do this that way and do that this way.(think of why there is non-addslashed code which lead to sql injection, and use of eval which lead to php injection, and .. ) +1 for "ifsetor" but btw, "ifsetor" might be complex for non-englishs. "default" might be better. -----
> $value = (integer) (isset($myBigArray['SomeKey1']['SomeOtherKey']) ? > $myBigArray['SomeKey1']['SomeOtherKey'] : 0); > > where > > $value = ifsetor($myBigArray['SomeKey1']['SomeOtherKey'], 0); > > is a bit cleaner.
no, it's a lot!

Nick Loeve

21 years ago
Xuefer wrote:
> > +1 for "ifsetor" > but btw, "ifsetor" might be complex for non-englishs. "default" might be better.
'default' is a reserved word.

Marcus Boerger

21 years ago
Hello Andi, Sunday, June 5, 2005, 9:13:52 PM, you wrote:
> At 07:18 PM 6/5/2005 +0200, Marcus Boerger wrote: >>There are a few things i'd like to address before: >> >>4) I still want the ifsetor operator since it is very helpfull and again >>simplifies a lot of things.
> I don't think ifsetor() shortcut is a big deal nor needed in PHP. I've said > it numerous times. Once we have a filtering API there will be even less > times where it will be applicable. Write an extra 10 characters or so...
One of the major features of "ifsetor()" against "isset()?:" is that the first can be twice as fast and is much more readable. You also said numerous times it has nothing to do with input filtering :-) marcus