RE: [PHP-DEV] Re: [RFC] ifsetor operator
| From: | Jason Garber | Date: | Sat, 17 Apr 2004 00:27:48 +0000 |
| Subject: | RE: [PHP-DEV] Re: [RFC] ifsetor operator | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-9306@lists.php.net to get a copy of this message | ||
In our code, you will find many blocks looking like
$CUST_ID = (integer) (isset($_POST['CUST_ID']) ? $_POST['CUST_ID'] : 0);
$CONTACT_ID = (integer) (isset($_POST['CONTACT_ID']) ? $_POST['CONTACT_ID'] : 0);
And when you want to read an element from an array that may or may not exist, you see this:
foreach($struct as $aValue)
{
$total += htmlspecialchars(isset($aValue['foo']['bar']['baz']) ? $aValue['foo']['bar']['baz'] : 0)
}
or if you want to print $sError, but it may or may not exist, you'll see
<?php if(isset($sError)) echo htmlspecialchars($sError); ?>
What it amounts to is duplicating your variable many places. It's not a big deal, but the existence of the ifsetor() function would really clean things up.
It really doesn't have as much value outside of E_ALL error mode, but has *tremendous* value when developing in E_ALL error mode.
~Jason
At 4/16/2004 05:05 PM -0700, Sterling Hughes wrote:
How about, if (isset($b)) { $a = $b; } else { $a = 10; } Or is that a bit too revolutionary? :) The problems with these operators is that the logic you want here is rarely simple, and when you need to refactor, you need to change your construct back to if{}else{} often introducing bugs. I see no reason to save ~ 10 keystrokes at the cost of readability. -Sterling -----Original Message----- From: Marcus Boerger [mailto:helly@php.net] Sent: Friday, April 16, 2004 3:29 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Re: [RFC] ifsetor operator Hello Andi, Saturday, April 17, 2004, 12:17:49 AM, you wrote: I don't want to spoil the party but: a) I don't think we should add a new reserved word for this. I will try and think of an alternative which uses the existing vocabulary. b) I would not want to add this before releasing PHP 5.0.0. I think we should add it afterwards. We are not talking about a trivial patch here and I believe that we should be in a deep feature freeze especially when it comes to the core. c) As this is a new feature and people have done without it up to now, I see no reason not to think of a good solution and wait with its implementation. I've already talked to Marcus about this in the past and he agreed not to make anymore such patches. It's not the first time where such harmless engine changes were discovered to have more widespread effects. yes we should wait until after 5.0. I never meant this to be commited to 5.0. But having the patch at hand gives the people to play with it. And i guess enough people know how to change the keyword. Having said this i hope we reach a consensus on either a good name or a new operator. marcus -- Best regards,Marcus mailto:helly@php.net-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php