Hello Internals team,
Thank you for taking a moment to evaluate a serious request by a serious
php developer that is responsible for a development company of 15 employees.
In order to keep our code as clean and error free as possible, we opt to
develop in the E_ALL error mode, and register_globals = off. This comes
with several challenges that one does not normally encounter.
We define and cast incoming script data variables at the top of each script,
so they are always defined and contain a valid value. Before E_ALL was
used, the form of this was:
$nCustID = (integer) $_POST['nCustID'];
and from that point on, the variables $nCustID and $sName would be used.
However when we started using E_ALL, these lines of code would throw
E_NOTICE level errors when the variable did not exist in the $_POST array.
So now, we use the form:
$nCustID = (integer) (isset($_POST['nCustID']) ? $_POST['nCustID'] : 0));
I know that writing a line like the following would be a solution, but when
evaluated closely, it is a very slow and clumsy one, especially if you are
using a custom error handler.
@ $nCustID = (integer) $_POST['nCustID'];
There is nothing wrong with writing lines of code like
$nCustID = (integer) (isset($_POST['nCustID']) ? $_POST['nCustID'] : 0));
everywhere, but it does tend to make the code very messy.
The feature that I am proposing is a language construct, and therefore would
need integrated into the ZEND engine. It is very simple, and would be
modeled after isset().
Function:
setor(arg1, arg2) -- if parameter 1 is set, then return it, else evaluate
and return parameter 2.
Example:
$nCustID = (integer) setor($_POST['nCustID'], 0);
I would imagine that the ( ? : ) operator only evaluates the second or third
argument if they are actually used, and the setor() function should behave
the same. Therefore, it would allow for expressions such as:
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
As you can see, it would reduce and un-duplicate quite a bit of code, making
PHP an even more easy to use language. Please evaluate this request
carefully, and then let me know your thoughts on it.
Sincerely,
Jason Garber
President and Chief Technology Officer
IonZoft, Inc. :: 814.742.8030
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
$z = setor($_GET['z'], 'Default');
Whats wrong with defining a user-level function?
function setor_array(&$array, $key, $default = 0)
{
return isset($array[$key']) ? $array[$key] : $default;
}
$nCustID = (int) setor_array($_GET, 'nCustID', 0);
Justin Hannus wrote:
Whats wrong with defining a user-level function?
actualy in this special case i have been whishing for an operator for ages,
maybe a modification of the good old ternary:
$foo = ?$bar : "default";
or
$foo ?= "default";
;)
--
Hartmut Holzgraefe <hartmut@php.net
Hartmut Holzgraefe wrote:
or
$foo ?= "default";
Looks Too Much Like Perl. IMO, if this is to be implemented, a function
should be created, and not a set of operators.
Olivier
GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---)
!O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++
h(*) r y+(?)
Quoting Hartmut Holzgraefe hartmut@php.net:
actualy in this special case i have been whishing for an operator for ages,
maybe a modification of the good old ternary:$foo = ?$bar : "default";
or
$foo ?= "default";
If this were added, wouldn't it make sense to use the convention
already adopted
by perl?
$foo |= 'default';
-chuck
--
"Regard my poor demoralized mule!" - Juan Valdez
Quoting Hartmut Holzgraefe hartmut@php.net:
[...]
If this were added, wouldn't it make sense to use the convention
already adopted
by perl?$foo |= 'default';
Already used:
$ php -r '$a= 1; $a |= 2; var_dump($a);'
int(3)
- Timm
Quoting Hartmut Holzgraefe hartmut@php.net:
[...]
If this were added, wouldn't it make sense to use the convention
already adopted
by perl?$foo |= 'default';
Already used:
$ php -r '$a= 1; $a |= 2; var_dump($a);'
int(3)
perl's is ||= anyway.
George
Hello Justin,
Thursday, April 15, 2004, 5:28:29 PM, you wrote:
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
$z = setor($_GET['z'], 'Default');
Whats wrong with defining a user-level function?
function setor_array(&$array, $key, $default = 0)
{
return isset($array[$key']) ? $array[$key] : $default;
}
$nCustID = (int) setor_array($_GET, 'nCustID', 0);
Such a user function would be todays best practice since
neither a userfunction setor($val, $else) nor an internal implementation
of such a function would work. Here Derick's argument comes into place that
we cannot simply change the way variables and array offsets are accessed.
The above setor_array() doesn't have that problem though.
--
Best regards,
Marcus mailto:helly@php.net
At 4/15/2004 11:28 AM -0400, Justin Hannus wrote:
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
$z = setor($_GET['z'], 'Default');Whats wrong with defining a user-level function?
function setor_array(&$array, $key, $default = 0)
{
return isset($array[$key']) ? $array[$key] : $default;
}$nCustID = (int) setor_array($_GET, 'nCustID', 0);
My issue with defining a user level function is:
a. the actual variable in question could not be passed
b. it incurs the overhead of calling a user-level function
I do admit that this may be a plausible solution for the majority of my
examples in initializing the incoming script variables, but does not
address the general problem of developing with E_NOTICE turned on - for
instance, accessing globals or deep arrays that may or may not exist.
It is one of the great features of PHP - accessing an undefined variable,
but one that is completely removed when E_NOTICE is turned on.
What is the overhead of calling a simple UDF in php?
~Jason Garber
a. the actual variable in question could not be passed
b. it incurs the overhead of calling a user-level function
Which takes about as much time as calling an internal function, so that
argument is bogus.
Derick
I am not sure what would be the best name for such an engine construct or a
function, but the idea itself is good (IMHO). It would certainly make it
easier to write safer notice free code.
Ilia
That is basically the same idea once proposed as extending
the ternary operator (credit goes to GCC and its C extension).
$bar ? : $baz;
If $bar evaluates to true, the expression evaluates to $bar
or to 0, respectively.
- Sascha
Is there a good reason to NOT implement this?
If not, I'm +1 on that (if I carry ANY weight at all (-: )
BC isn't an issue, and it would be a very useful feature, IMHO..
S
Sascha Schumann wrote:
That is basically the same idea once proposed as extending the ternary operator (credit goes to GCC and its C extension). $bar ? : $baz; If $bar evaluates to true, the expression evaluates to $bar or to 0, respectively. - Sascha
Sascha Schumann wrote:
That is basically the same idea once proposed as extending the ternary operator (credit goes to GCC and its C extension). $bar ? : $baz;
yes, that looks like the way it should look like,
and the danger of newbees abusing it would be way lower
than with a function ... ;)
--
Hartmut Holzgraefe <hartmut@php.net
+1 for the GCC style syntax.
--Wez.
----- Original Message -----
From: "Hartmut Holzgraefe" hartmut@php.net
To: "Sascha Schumann" sascha@schumann.cx
Cc: "Ilia Alshanetsky" ilia@prohost.org; internals@lists.php.net
Sent: Thursday, April 15, 2004 8:47 PM
Subject: Re: [PHP-DEV] Construct Request
Sascha Schumann wrote:
That is basically the same idea once proposed as extending the ternary operator (credit goes to GCC and its C extension). $bar ? : $baz;yes, that looks like the way it should look like,
and the danger of newbees abusing it would be way lower
than with a function ... ;)