# Before March 1st aka PHP 5.1 beta - Thread: https://externals.io/message/15052 - Original archive: https://news-web.php.net/php.internals/15052 - Started by Marcus Boerger on 2005-02-17T19:18:53+00:00 - Messages: 24 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #15052 — Marcus Boerger — 2005-02-17T19:18:53+00:00 URL: https://externals.io/message/15052#15052 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 --- ## #15053 — Rasmus Lerdorf — 2005-02-17T19:23:28+00:00 URL: https://externals.io/message/15052#15053 · In reply to: #15052 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 --- ## #15055 — Andi Gutmans — 2005-02-17T19:49:44+00:00 URL: https://externals.io/message/15052#15055 · In reply to: #15052 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 --- ## #15056 — Ron Korving — 2005-02-17T19:59:35+00:00 URL: https://externals.io/message/15052#15056 · In reply to: #15052 > 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 --- ## #15057 — Wez Furlong — 2005-02-17T20:03:04+00:00 URL: https://externals.io/message/15052#15057 · In reply to: #15055 > 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. --- ## #15058 — Daniel Convissor — 2005-02-17T20:04:17+00:00 URL: https://externals.io/message/15052#15058 · In reply to: #15055 > At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote: > > […] > > 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 --- ## #15061 — Jason Garber — 2005-02-17T20:05:59+00:00 URL: https://externals.io/message/15052#15061 · In reply to: #15055 Hello Andi, > > […] 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 --- ## #15059 — Marcus Boerger — 2005-02-17T20:06:04+00:00 URL: https://externals.io/message/15052#15059 · In reply to: #15055 Hello Andi, Thursday, February 17, 2005, 8:49:44 PM, you wrote: > At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote: > > […] > 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 --- ## #15060 — l0t3k — 2005-02-17T20:06:52+00:00 URL: https://externals.io/message/15052#15060 · In reply to: #15052 Marcus, a minor but important issue (to me, at least) is the consistent use of SPL exceptions throughout OOP based extensions... "Marcus Boerger" 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. --- ## #15067 — Christian Schneider — 2005-02-17T20:37:59+00:00 URL: https://externals.io/message/15052#15067 · In reply to: #15056 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 --- ## #15071 — Ron Korving — 2005-02-17T22:08:31+00:00 URL: https://externals.io/message/15052#15071 · In reply to: #15067 You're absolutely right... It should've said "notemptyor" :) Very perceptive ;) Ron "Christian Schneider" wrote in message news:421500A7.4040209@cschneid.com... > Ron Korving wrote: > > […] > > 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 --- ## #15072 — Ron Korving — 2005-02-17T22:10:55+00:00 URL: https://externals.io/message/15052#15072 · In reply to: #15052 A little offtopic, but I'm still curious.. is multiple inheritence something we might see appearing in 5.2 ? Ron "Marcus Boerger" 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. > 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 --- ## #15073 — Adam Maccabee Trachtenberg — 2005-02-17T22:18:15+00:00 URL: https://externals.io/message/15052#15073 · In reply to: #15072 > 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! --- ## #15074 — Andi Gutmans — 2005-02-17T22:26:44+00:00 URL: https://externals.io/message/15052#15074 · In reply to: #15052 Nope. Interfaces is supported as an alternative approach to MI. Andi At 11:10 PM 2/17/2005 +0100, Ron Korving wrote: >A little offtopic, but I'm still curious.. is multiple inheritence something >we might see appearing in 5.2 ? > >Ron > >"Marcus Boerger" wrote in message >news:59089102.20050217201853@marcus-boerger.de... > > […] >feature. > > […] --- ## #15076 — Marcus Boerger — 2005-02-17T22:32:33+00:00 URL: https://externals.io/message/15052#15076 · In reply to: #15072 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 --- ## #15078 — Ron Korving — 2005-02-17T22:46:08+00:00 URL: https://externals.io/message/15052#15078 · In reply to: #15076 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" wrote in message news:1334163369.20050217233233@marcus-boerger.de... > Hello Ron, > > Thursday, February 17, 2005, 11:10:55 PM, you wrote: > > > […] something > > […] > > 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 --- ## #15079 — Marcus Boerger — 2005-02-17T22:52:34+00:00 URL: https://externals.io/message/15052#15079 · In reply to: #15055 Hello Andi, Thursday, February 17, 2005, 8:49:44 PM, you wrote: > At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote: > > […] > 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 --- ## #15080 — Jason Garber — 2005-02-17T22:55:53+00:00 URL: https://externals.io/message/15052#15080 · In reply to: #15078 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" wrote in message RK> news:1334163369.20050217233233@marcus-boerger.de... > > […] RK> something > > […] --- ## #15081 — l0t3k — 2005-02-17T23:05:41+00:00 URL: https://externals.io/message/15052#15081 · In reply to: #15078 "Ron Korving" 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. > Ron --- ## #15082 — Ryan King — 2005-02-18T03:38:44+00:00 URL: https://externals.io/message/15052#15082 · In reply to: #15080 > 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" wrote in message > RK> news:1334163369.20050217233233@marcus-boerger.de... > > […] > RK> something > > […] > > -- > > > > -- http://theryanking.com/blog --- ## #15085 — Sebastian Bergmann — 2005-02-18T06:34:13+00:00 URL: https://externals.io/message/15052#15085 · In reply to: #15072 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 --- ## #15086 — Lukas Smith — 2005-02-18T07:57:05+00:00 URL: https://externals.io/message/15052#15086 · In reply to: #15085 Sebastian Bergmann wrote: > Ron Korving wrote: > > > […] > > > 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 --- ## #15160 — Lukas Smith — 2005-02-22T22:54:43+00:00 URL: https://externals.io/message/15052#15160 · In reply to: #15052 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 --- ## #15163 — Greg Beaver — 2005-02-23T06:44:24+00:00 URL: https://externals.io/message/15052#15163 · In reply to: #15160 Lukas Smith wrote: > Marcus Boerger wrote: > > > […] > > > 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