Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Before March 1st aka PHP 5.1 beta »

Before March 1st aka PHP 5.1 beta

php.internals

Marcus Börger

21 years ago
Hello internals, before we rush into another version, how about clearing some open issues that were explicitly relayed from 5.0 to 5.1. 1) __toString() There was a problem with the Zend engine 2.0 that forced us to drop this feature. Now that we have 2.1 we should check again and readd the feature. Since PHP is designed to generate string output i think that should be made as easy as possible. And after learning echo and '.' it is hard to explain that 'echo $foo . $bar' could result in something different than 'echo $foo, $bar'. Besides if it turned out that there is still a reentrance problem then we'd need to remove __call, __get, __set, iterators..... 2) type hinting and NULL We decided to find a way to handle NULL. Iirc then we settled down on allowing 'foo(BLA $obj = NULL) which could be easily added. 3) type hinting and arrays We decided that we want typehinting for arrays since that is a very special kind. Since my array-typehinting patch was considered 'not so nice' i hope somebody else has a better idea. 4) php 5.1 is aiming to increase performance and security => ifsetor It is nice and easy and fast...only it's name. Well guys come on that's the stupiest reason to reject. The name is selfspeaking, you're all only not so used to its name as you are with foreach for now. 5) did we came to a conclusion on Rasmus' input filtering yet Since we said we aim to increase security with 5.1 we should incorporate that idea/technique in some way.
-- Best regards, Marcus

Rasmus Lerdorf

21 years ago
Marcus Boerger wrote:
> 4) php 5.1 is aiming to increase performance and security => ifsetor > > It is nice and easy and fast...only it's name. Well guys come on that's > the stupiest reason to reject. The name is selfspeaking, you're all only > not so used to its name as you are with foreach for now.
I think ifsetor is a useful shortcut for something people do a lot.
> 5) did we came to a conclusion on Rasmus' input filtering yet > > Since we said we aim to increase security with 5.1 we should incorporate > that idea/technique in some way.
I don't think I am going to have it ready that fast. I'll commit something to pecl soon but I am tied up with some really annoying time-wasting stuff right now. -Rasmus

Andi Gutmans

21 years ago
At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
>Hello internals, > > before we rush into another version, how about clearing some open issues >that were explicitly relayed from 5.0 to 5.1. > >1) __toString() > > There was a problem with the Zend engine 2.0 that forced us to drop this > feature. Now that we have 2.1 we should check again and readd the feature. > Since PHP is designed to generate string output i think that should be > made as easy as possible. And after learning echo and '.' it is hard to > explain that 'echo $foo . $bar' could result in something different than > 'echo $foo, $bar'. Besides if it turned out that there is still a > reentrance problem then we'd need to remove __call, __get, __set, > iterators.....
Yes, I think we could revisit this. It should work right now although I'm still skeptical about what place to put this and what not. If I recall you wanted convert_to_string() and all other places to support this, right? Also, I would like to add serialize/unserialize callbacks for internal extensions so that they can take part in session handling. Stas has already started looking into it and it's probably a relatively small patch.
>2) type hinting and NULL > > We decided to find a way to handle NULL. Iirc then we settled down on > allowing 'foo(BLA $obj = NULL) which could be easily added.
We didn't settle for anything here. We came to the conclusion that we could not find a good syntax for it and that the syntax you are proposing is ambiguous.
>3) type hinting and arrays > > We decided that we want typehinting for arrays since that is a very > special kind. Since my array-typehinting patch was considered 'not so > nice' i hope somebody else has a better idea.
My main problem is the implementation. I don't think this is critical for 5.1 at all.
>4) php 5.1 is aiming to increase performance and security => ifsetor > > It is nice and easy and fast...only it's name. Well guys come on that's > the stupiest reason to reject. The name is selfspeaking, you're all only > not so used to its name as you are with foreach for now.
It wasn't only the name but also the implementation. Actually, I was hoping that the input filter API would resolve this issue once and for all even if in a bit of a different (and IMO better) way.
>5) did we came to a conclusion on Rasmus' input filtering yet > > Since we said we aim to increase security with 5.1 we should incorporate > that idea/technique in some way.
Yes. It's a good thing but I don't think it has to be in 5.1. We should add it when everyone feels comfortable with it and Rasmus has time to work on it. 6) Still need to integrate PDO into the build system. I emailed Wez about this. I see this a show stopper for 5.1. Basically I think --with-db should build both ext/db and ext/pd_db. Marcus, 5.1 doesn't have to include everything. The way I see it the current improvements in the code base and PDO make for a great .1 release. I prefer not making mistakes with features especially when they are issues which aren't critical (and I really think they aren't). Andi

Wez Furlong

21 years ago
On Thu, 17 Feb 2005 11:49:44 -0800, Andi Gutmans <andi@zend.com> wrote:
> 6) Still need to integrate PDO into the build system. I emailed Wez about > this. I see this a show stopper for 5.1. Basically I think --with-db should > build both ext/db and ext/pd_db.
I already made a start on this last night (PDO is there in HEAD now). Not sure if I'll have time to tackle the build system over the next few days (have a lot of work and actual PDO coding to fit in). I think we still have time to get this working. --Wez.

Daniel Convissor

21 years ago
On Thu, Feb 17, 2005 at 11:49:44AM -0800, Andi Gutmans wrote:
> At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
> >4) php 5.1 is aiming to increase performance and security => ifsetor > > It wasn't only the name but also the implementation. Actually, I was hoping > that the input filter API would resolve this issue once and for all even if > in a bit of a different (and IMO better) way.
This function has more uses than input filtering. --Dan
-- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Marcus Börger

21 years ago
Hello Andi, Thursday, February 17, 2005, 8:49:44 PM, you wrote:
> At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote: >>Hello internals, >> >> before we rush into another version, how about clearing some open issues >>that were explicitly relayed from 5.0 to 5.1. >> >>1) __toString() >> >> There was a problem with the Zend engine 2.0 that forced us to drop this >> feature. Now that we have 2.1 we should check again and readd the feature. >> Since PHP is designed to generate string output i think that should be >> made as easy as possible. And after learning echo and '.' it is hard to >> explain that 'echo $foo . $bar' could result in something different than >> 'echo $foo, $bar'. Besides if it turned out that there is still a >> reentrance problem then we'd need to remove __call, __get, __set, >> iterators.....
> Yes, I think we could revisit this. It should work right now although I'm > still skeptical about what place to put this and what not. If I recall you > wanted convert_to_string() and all other places to support this, right? > Also, I would like to add serialize/unserialize callbacks for internal > extensions so that they can take part in session handling. Stas has already > started looking into it and it's probably a relatively small patch.
Damn i knew i have forgotten something. I had some ideas for that but no imlementation time. If he wants he could contact me of course :-) regards marcus

Jason Garber

21 years ago
Hello Andi,
>>4) php 5.1 is aiming to increase performance and security => ifsetor >> >> It is nice and easy and fast...only it's name. Well guys come on that's >> the stupiest reason to reject. The name is selfspeaking, you're all only >> not so used to its name as you are with foreach for now.
AG> It wasn't only the name but also the implementation. Actually, I was hoping AG> that the input filter API would resolve this issue once and for all even if AG> in a bit of a different (and IMO better) way. Input filtering does not solve the problem ifsetor() is designed to solve. It tackles a small part of it, but ifsetor() is a general purpose construct that is used for $_GET, $_POST, as well as ANY OTHER array element or variable in your script. $x = ifsetor($somearray[$foo][$bar], 0); Is a lot cleaner than: $x = isset($somearray[$foo][$bar]) ? $somearray[$foo][$bar] : 0;
-- ifsetor()'s purpose is simple and clear: To return a variable value if it exists or a default value if it does not exist WITHOUT generating any error. Thanks. -- Best regards, Jason mailto:jason@ionzoft.com

Andi Gutmans

21 years ago
At 03:03 PM 2/17/2005 -0500, Wez Furlong wrote:
>On Thu, 17 Feb 2005 11:49:44 -0800, Andi Gutmans <andi@zend.com> wrote: > > 6) Still need to integrate PDO into the build system. I emailed Wez about > > this. I see this a show stopper for 5.1. Basically I think --with-db should > > build both ext/db and ext/pd_db. > >I already made a start on this last night (PDO is there in HEAD now). >Not sure if I'll have time to tackle the build system over the next >few days (have a lot of work and actual PDO coding to fit in). > >I think we still have time to get this working.
I'd prefer to have it in the beta. I don't mind waiting with the beta for it. Are there any build magicians here that will have time to help Wez? Andi

Andi Gutmans

21 years ago
Yeah I realize it's different but my idea was that if you have something like: filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some other function could be: if (isset($_POST["foo"]) && is_number(..... I think in most cases that would do and doesn't require to add/change opcodes and language constructs... Andi At 03:05 PM 2/17/2005 -0500, Jason Garber wrote:

Daniel Convissor

21 years ago
On Thu, Feb 17, 2005 at 12:21:45PM -0800, Andi Gutmans wrote:
> Yeah I realize it's different but my idea was that if you have something > like: > filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some other > function could be: > if (isset($_POST["foo"]) && is_number(..... > > I think in most cases that would do and doesn't require to add/change > opcodes and language constructs...
Yeah, but... what if one wants to call it on a variable that's not part of the superglobals? Plus that construct doesn't provide a way to set the default value for the particular variable at hand. --Dan
-- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Andi Gutmans

21 years ago
At 03:26 PM 2/17/2005 -0500, Daniel Convissor wrote:
>On Thu, Feb 17, 2005 at 12:21:45PM -0800, Andi Gutmans wrote: > > Yeah I realize it's different but my idea was that if you have something > > like: > > filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some other > > function could be: > > if (isset($_POST["foo"]) && is_number(..... > > > > I think in most cases that would do and doesn't require to add/change > > opcodes and language constructs... > >Yeah, but... what if one wants to call it on a variable that's not part of >the superglobals? Plus that construct doesn't provide a way to set the >default value for the particular variable at hand.
Well the API could allow the option to provide a default value if the data doesn't match the input. That's why I used the word "could" because the API for the input filtering hasn't been finalized. Andi

Lukas Smith

21 years ago
Andi Gutmans wrote:
> At 03:26 PM 2/17/2005 -0500, Daniel Convissor wrote: > >> On Thu, Feb 17, 2005 at 12:21:45PM -0800, Andi Gutmans wrote: >> > Yeah I realize it's different but my idea was that if you have >> something >> > like: >> > filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some >> other >> > function could be: >> > if (isset($_POST["foo"]) && is_number(..... >> > >> > I think in most cases that would do and doesn't require to add/change >> > opcodes and language constructs... >> >> Yeah, but... what if one wants to call it on a variable that's not >> part of >> the superglobals? Plus that construct doesn't provide a way to set the >> default value for the particular variable at hand. > > > Well the API could allow the option to provide a default value if the > data doesn't match the input. That's why I used the word "could" because > the API for the input filtering hasn't been finalized.
input filtering is not supposed to set defaults. so I would very much recommend not mixing the two. regards, Lukas

Marcus Börger

21 years ago
Hello Andi, Thursday, February 17, 2005, 8:49:44 PM, you wrote:
> At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote: >>Hello internals, >> >> before we rush into another version, how about clearing some open issues >>that were explicitly relayed from 5.0 to 5.1. >> >>1) __toString() >> >> There was a problem with the Zend engine 2.0 that forced us to drop this >> feature. Now that we have 2.1 we should check again and readd the feature. >> Since PHP is designed to generate string output i think that should be >> made as easy as possible. And after learning echo and '.' it is hard to >> explain that 'echo $foo . $bar' could result in something different than >> 'echo $foo, $bar'. Besides if it turned out that there is still a >> reentrance problem then we'd need to remove __call, __get, __set, >> iterators.....
> Yes, I think we could revisit this. It should work right now although I'm > still skeptical about what place to put this and what not. If I recall you > wanted convert_to_string() and all other places to support this, right?
For PHP 5.0 we used to have a special conversion make_printable - i guess we shouldn't go that way again if there's no need and instead simply call the objects conversion handler that could (again) call __toString() if it is present. What do you think?
-- Best regards, Marcus mailto:helly@php.net

Ron Korving

21 years ago
> 4) php 5.1 is aiming to increase performance and security => ifsetor > > It is nice and easy and fast...only it's name. Well guys come on that's > the stupiest reason to reject. The name is selfspeaking, you're all only > not so used to its name as you are with foreach for now.
I really love this idea a lot, but I hope there will be an ifemptyor() as well.. Maybe these names could be considered: "setor" and "emptyor" setor($foo, "bar"); emptyor($foo, "bar"); or if they won't be call by reference: $foo = setor($foo, "bar"); $foo = emptyor($foo, "bar"); I really like this idea, and I don't know if it will be by-reference, but if they would, then I think it would be nice to have them return a boolean which is False if the alternative was used and True otherwise. Just my 0.02 euro. Ron

Christian Schneider

21 years ago
Ron Korving wrote:
> $foo = emptyor($foo, "bar");
I'm not really sure that you'd use this for. Set $foo to either the original value (if $foo was empty before) or "bar"? Is that empty as in empty()? So you could end up with null, "", 0, "0", false or "bar"? - Chris

Ron Korving

21 years ago
You're absolutely right... It should've said "notemptyor" :) Very perceptive ;) Ron "Christian Schneider" <cschneid@cschneid.com> wrote in message news:421500A7.4040209@cschneid.com...

l0t3k

21 years ago
Marcus, a minor but important issue (to me, at least) is the consistent use of SPL exceptions throughout OOP based extensions... "Marcus Boerger" <helly@php.net> wrote in message news:59089102.20050217201853@marcus-boerger.de...

Ron Korving

21 years ago
A little offtopic, but I'm still curious.. is multiple inheritence something we might see appearing in 5.2 ? Ron "Marcus Boerger" <helly@php.net> wrote in message news:59089102.20050217201853@marcus-boerger.de...
> Hello internals, > > before we rush into another version, how about clearing some open issues > that were explicitly relayed from 5.0 to 5.1. > > 1) __toString() > > There was a problem with the Zend engine 2.0 that forced us to drop this > feature. Now that we have 2.1 we should check again and readd the
feature.

Adam Maccabee Trachtenberg

21 years ago
On Thu, 17 Feb 2005, Ron Korving wrote:
> A little offtopic, but I'm still curious.. is multiple inheritence something > we might see appearing in 5.2 ?
No. -adam
-- adam@trachtenberg.com | http://www.trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today!

Marcus Börger

21 years ago
Hello Ron, Thursday, February 17, 2005, 11:10:55 PM, you wrote:
> A little offtopic, but I'm still curious.. is multiple inheritence something > we might see appearing in 5.2 ?
Definitively not. You may raise this question prior to PHP 6, However still getting the answer 'no'. The concept simply doesn't match with PHP and since we have multiple inheritance for interfaces that's enough. Best regards, Marcus mailto:helly@php.net

Ron Korving

21 years ago
Okay, I'll accept the "no" of course, but I am curious.. Is it an implementation problem with the current engine? Saying that using interfaces discards the MI issue is nonsense imho, because I can't implement any functions in an interface. So why is this such a big "no"? Implementation problem or is it against a certain PHP philosophy? Ron "Marcus Boerger" <helly@php.net> wrote in message news:1334163369.20050217233233@marcus-boerger.de...
> Hello Ron, > > Thursday, February 17, 2005, 11:10:55 PM, you wrote: > > > A little offtopic, but I'm still curious.. is multiple inheritence
something

Jason Garber

21 years ago
Hello, Speaking of these matters, how about implementing functions within interfaces?
-- Best regards, Jason mailto:jason@ionzoft.com Thursday, February 17, 2005, 5:46:08 PM, you wrote: RK> Okay, I'll accept the "no" of course, but I am curious.. Is it an RK> implementation problem with the current engine? Saying that using interfaces RK> discards the MI issue is nonsense imho, because I can't implement any RK> functions in an interface. RK> So why is this such a big "no"? Implementation problem or is it against a RK> certain PHP philosophy? RK> Ron RK> "Marcus Boerger" <helly@php.net> wrote in message RK> news:1334163369.20050217233233@marcus-boerger.de... >> Hello Ron, >> >> Thursday, February 17, 2005, 11:10:55 PM, you wrote: >> >> > A little offtopic, but I'm still curious.. is multiple inheritence RK> something

Ryan King

21 years ago
On Feb 17, 2005, at 2:55 PM, Jason Garber wrote:
> Hello, > > Speaking of these matters, how about implementing functions within > interfaces?
That is by definition impossible. Instead of being an interface, it would be an implementation. -ryan
> -- > Best regards, > Jason mailto:jason@ionzoft.com > > Thursday, February 17, 2005, 5:46:08 PM, you wrote: > > RK> Okay, I'll accept the "no" of course, but I am curious.. Is it an > RK> implementation problem with the current engine? Saying that using > interfaces > RK> discards the MI issue is nonsense imho, because I can't implement > any > RK> functions in an interface. > > RK> So why is this such a big "no"? Implementation problem or is it > against a > RK> certain PHP philosophy? > > RK> Ron > > RK> "Marcus Boerger" <helly@php.net> wrote in message > RK> news:1334163369.20050217233233@marcus-boerger.de... >>> Hello Ron, >>> >>> Thursday, February 17, 2005, 11:10:55 PM, you wrote: >>> >>>> A little offtopic, but I'm still curious.. is multiple inheritence > RK> something >>>> we might see appearing in 5.2 ? >>> >>> Definitively not. >>> You may raise this question prior to PHP 6, >>> However still getting the answer 'no'. >>> The concept simply doesn't match with PHP >>> and since we have multiple inheritance for >>> interfaces that's enough. >>> >>> Best regards, >>> Marcus mailto:helly@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- http://theryanking.com/blog

l0t3k

21 years ago
"Ron Korving" <r.korving@xit.nl> wrote in message news:20050217224614.21062.qmail@lists.php.net...
> So why is this such a big "no"? Implementation problem or is it against a > certain PHP philosophy?
Just do a google search on the cons of MI (narrow it to C++ if you please). it's much more a philosophical issue, although i'd still raise practicality issues over efficiency in a scripting environment. not to mention numerous implementation issues which are too easy to get wrong.

Sebastian Bergmann

21 years ago
Ron Korving wrote:
> is multiple inheritence something we might see appearing in 5.2 ?
The concept of Multiple Inheritance should be left to programming languages that can properly deal with it (by letting the programmer influence how inheritance collision can be resolved, for instance). Multiple Inheritance is one feature that I do not want to see in PHP. And since we have interfaces (for which we allow multiple inheritance) I do not see a need for Multiple Inheritance; interfaces are a much cleaner way to model.
-- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Lukas Smith

21 years ago
Sebastian Bergmann wrote:
> Ron Korving wrote: > >>is multiple inheritence something we might see appearing in 5.2 ? > > > The concept of Multiple Inheritance should be left to programming > languages that can properly deal with it (by letting the programmer > influence how inheritance collision can be resolved, for instance). > > Multiple Inheritance is one feature that I do not want to see in PHP. > And since we have interfaces (for which we allow multiple inheritance) I > do not see a need for Multiple Inheritance; interfaces are a much > cleaner way to model.
Also we have __call() to help you in not having to cut and paste implementations around. regards, Lukas

Andi Gutmans

21 years ago
Nope. Interfaces is supported as an alternative approach to MI. Andi At 11:10 PM 2/17/2005 +0100, Ron Korving wrote:

Lukas Smith

21 years ago
Marcus Boerger wrote:
> Hello internals, > > before we rush into another version, how about clearing some open issues > that were explicitly relayed from 5.0 to 5.1.
I would like to highlight again that getting the pear installer version 1.4 will also be important. getting this into php 5.1 will improve the life for pecl considerably! Greg has been working really hard on getting this stuff far along and now we need testers just like PDO to get this stuff stable. Especially with Wez being very busy with PDO its important that other people form internals step up to ensure that all the new features for PECL work well in the real world. regards, Lukas

Greg Beaver

21 years ago
Lukas Smith wrote:
> Marcus Boerger wrote: > >> Hello internals, >> >> before we rush into another version, how about clearing some open >> issues >> that were explicitly relayed from 5.0 to 5.1. > > > I would like to highlight again that getting the pear installer version > 1.4 will also be important. getting this into php 5.1 will improve the > life for pecl considerably! > > Greg has been working really hard on getting this stuff far along and > now we need testers just like PDO to get this stuff stable. Especially > with Wez being very busy with PDO its important that other people form > internals step up to ensure that all the new features for PECL work well > in the real world.
I plan to release PEAR 1.4.0a1 this week. Although this version should not be included in PHP 5.1 beta 1, I expect that barring any disasters, the first beta should be ready by PHP 5.1 beta 2. In the mean time, the release of a1 will give me a chance to fine-tune the install-pear.php script and other factors that go into the release process. What makes more sense: sticking with PEAR 1.3.5 for PHP 5.1 stable, or trying to get PEAR 1.4.0 stable into PHP 5.1 stable? If 5.1 stable is planned for no sooner than May/June, this is no problem. Earlier than that might be pushing it, but who knows, the current release is very stable, it is only alpha because features may need to change after users have a chance to try them out. Greg