$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:[EMAIL PROTECTED] Sent: Friday, April 16, 2004 3:29 PM To: Andi Gutmans Cc: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
