Everything

php

Home » Project » Newsgroups » php.internals » Construct Request »

Construct Request

php.internals

Jason Garber

22 years ago

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

Justin Hannus

22 years ago

> 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);

Ferdinand Beyer

22 years ago

On 15 Apr 2004 at 11:47, Jason Garber wrote:

> a. the actual variable in question could not be passed

This is wrong, too. Look at this example:

<?php
error_reporting(E_ALL | E_STRICT);

function param(&$param, $default, $type = null)
{
if (!isset($param)) {
$param = $default;
}
if (is_string($type)) {
settype($param, $type);
}
}

$_GET['Exists'] = 0;

param($_GET['Exists'], 1, 'string');
param($_GET['Does']['Not']['Exist'], 1, 'double');

var_dump($_GET);
?>

Output:
----------------------------------------
array(2) {
["Exists"]=>
string(1) "0"
["Does"]=>
array(1) {
["Not"]=>
array(1) {
["Exist"]=>
float(1)
}
}
}

Exactly the behavior you are looking for. Not even an E_NOTICE.

--
Ferdinand Beyer
<fb@fbeyer.com>

Todd Ruth

22 years ago

The thing I like about the suggestion over implementing
the function in script is the ability to skip the call to
a function that provides the default.  In the following
example, slowFunc() simulates a slow function using a sleep,
but you can imagine any function call with a performance
hit.  The script version of setor takes the performance hit
whether it needs to or not.  The internal version could
only take the hit when necessary.  Likewise for avoiding
calls that have more effects than generating a default.

<?php
error_reporting(E_ALL | E_STRICT);
function slowFunc() {
sleep(10);
return 2;
}

function getor($param, $default){
if (!isset($param)) {
return $default;
}
return $param;
}
$_GET['whatever'] = 5;
$x = getor(@$_GET['whatever'], slowFunc());  // Long wait for no-op
var_dump($x);
flush();
unset($_GET['whatever']);
$x = getor(@$_GET['whatever'], slowFunc());
var_dump($x);
?>

- Todd

Justin Hannus

22 years ago

Actually, although suppressing the E_NOTICE, this is not exactly the
behavior you want.

What if $_GET['Does']['Not']['Exist'] really doesn't exists? It is then
created and assigned to $param when passed as an argument to the param
function. Therefore polluting $_GET with another unused array and array
element, creating more internal hashes for no reason. Try that with 50 form
vars and you be creating 50 more variables that really never even existed.
Maybe not much of a foot print but very unnecessary.

There are probably many different ways you can implement this functionality
at a user-level, try the php.general list.


"Ferdinand Beyer" <fb@fbeyer.com> wrote in message
news:407ED81A.21462.7D6A2@localhost...

Hartmut Holzgraefe

22 years ago

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>

Olivier Hill

22 years ago

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+(?)

Chuck Hagenbuch

22 years ago

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

Timm Friebe

22 years ago

On Thu, 2004-04-15 at 21:36, Chuck Hagenbuch wrote:

> 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

George Schlossnagle

22 years ago

On Apr 15, 2004, at 3:35 PM, Timm Friebe wrote:

> On Thu, 2004-04-15 at 21:36, Chuck Hagenbuch wrote:
>> 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

Marcus Börger

22 years ago

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

Jason Garber

22 years ago

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

Derick Rethans

22 years ago

On Thu, 15 Apr 2004, Jason Garber wrote:

> 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

Ilia A.

22 years ago

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

Sascha Schumann

22 years ago

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

Sean Coates

22 years ago

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:

Darrell Brogdon

22 years ago

+1

-----Original Message-----
From: Sean Coates [mailto:sean@caedmon.net]
Sent: Thursday, April 15, 2004 12:10 PM
To: Sascha Schumann
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Construct Request

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
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Andi Gutmans

22 years ago

It could be implemented but I don't see the big advantage over $bar ? 0 : $base
It's one character...

At 02:09 PM 4/15/2004 -0400, Sean Coates wrote:

Sean Coates

22 years ago

Andi Gutmans wrote:

> It could be implemented but I don't see the big advantage over $bar ? 0
> : $base
> It's one character...
> oes to GCC and its C extension).
>>>     $bar ? : $baz;
>>>     If $bar evaluates to true, the expression evaluates to $bar
>>>     or to 0, respectively.
>>

I think we're unclear on this..

What seems right to me:

<?php

$variable = $foo ?: $bar;

// is the same as

if ($foo) $variable = $foo; else $variable = $bar;

?>

I know that's not what Sascha originally wrote, but am I mistaken on the
actual meaning (I don't get the "0" reference made by Sascha)?

S

Ilia A.

22 years ago

On April 15, 2004 02:15 pm, Andi Gutmans wrote:

> It could be implemented but I don't see the big advantage over $bar ? 0 :
> $base It's one character...

Well, currently to check the value and assign the default you need to do the
following:

$_GET['foo'] = isset($_GET['foo']) ? (int) $_GET['foo'] : 0;

Which can get quite annoying if you need to repeat that many times and it's
just easier to disable notices and do $_GET['foo'] = (int) $_GET['foo'];

I think if anyone of the following would work it would be quite convenient

isset_or_default($_GET['foo'], 0);
/* if $_GET['foo'] is set leave as is, otherwise assign 0 to it */

$_GET['foo'] = isset_or_default($_GET['foo'], 0);
/* same as above, but the variable is not passed by reference */

isset($_GET['foo']) ? : 0;
/* Sascha's proposal */

Ilia

Jason Garber

22 years ago

The best functionality would be for it to return the value, not re-assign
it.  Many of the things being talked about would modify the sent parameter,
rather than return selected value.

For instance (using the isset_or_default()) call:

$nCustID = (int) isset_or_default($_POST['CUST_ID'], 0);

That would give the developer flexibility on how he used it, and could
reassign it to the $_POST array if he wanted to.

$_POST['CUST_ID'] = (int) isset_or_default($_POST['CUST_ID'], 0);

I agree that it would be helpful not to evaluate the second parameter
unless needed, which is why I originally proposed a language construct.

Also, I think that using an operator would add to the complexity of
thoroughly understanding the PHP language, which is something that I
understand we do not want to do.

~Jason Garber

At 4/15/2004 02:34 PM -0400, Ilia Alshanetsky wrote:

Derick Rethans

22 years ago

On Thu, 15 Apr 2004, Jason Garber wrote:

> $_POST['CUST_ID'] = (int) isset_or_default($_POST['CUST_ID'], 0);
>
> I agree that it would be helpful not to evaluate the second parameter
> unless needed, which is why I originally proposed a language construct.

You'll need something more clever, because an undefined
key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a warning, even if
you pass it to a language construct. Changing that behavior is not
trivial.

Derick

Jason Garber

22 years ago

Hi Derick,

I see.  I was basing the spec on the functionality of isset() which does
not (obviously) throw an E_NOTICE when you pass an undefined variable to
it.  However, do you see any reason that this would not reliably work?

function setor(&$param, $default)
{
return (isset($param) ? $param : $default);
}

I tested it on 4.3.4 and 5.0 RC1, and it worked.  Is passing an undefined
variable as a reference parameter a legal thing to do in PHP?

~Jason



At 4/15/2004 09:54 PM +0200, Derick Rethans wrote:

Derick Rethans

22 years ago

On Thu, 15 Apr 2004, Jason Garber wrote:

> I see.  I was basing the spec on the functionality of isset() which does
> not (obviously) throw an E_NOTICE when you pass an undefined variable to
> it.  However, do you see any reason that this would not reliably work?

I wrote this (I underlined the relevant parts for you):

> >You'll need something more clever, because
> >an undefined key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a

===============================================

> >warning, even if you pass it to a language construct. Changing that
> >behavior is not trivial.

Derick

Marcus Börger

22 years ago

Hello Derick,

Thursday, April 15, 2004, 10:07:01 PM, you wrote:

> On Thu, 15 Apr 2004, Jason Garber wrote:

>> I see.  I was basing the spec on the functionality of isset() which does
>> not (obviously) throw an E_NOTICE when you pass an undefined variable to
>> it.  However, do you see any reason that this would not reliably work?

> I wrote this (I underlined the relevant parts for you):

>> >You'll need something more clever, because
>> >an undefined key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a
>    ===============================================

>> >warning, even if you pass it to a language construct. Changing that
>> >behavior is not trivial.

Not really hard, we have several modes ofr accessing values. Some of them
allow error free access. Furthermore you can implement it in the following
way:

$var = $val ?: $else;

$var = if (isset($val)) $val else $else;

in contrast to

$var = if ($val) $val else $else;

Notice that the former implementation does not need any change in access
methods. It simply uses a different access for the test or better said it
creates a different test.


Best regards,
Marcus                            mailto:helly@php.net

Jason Garber

22 years ago

>I wrote this (I underlined the relevant parts for you):
>
> > >You'll need something more clever, because
> > >an undefined key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a

Consider this:

-----------------------------------
<?php

error_reporting(E_ALL);

function setor(&$param, $default)
{
return (isset($param) ? $param : $default);
}


$x = setor($x, 10);    ///Should Produce an E_NOTICE

echo gettype($x) . ':' . $x . "\n";

?>
-----------------------------------

This DOES NOT produce an E_NOTICE like you said (notice the &).  However,
$param1 is defined and NULL inside the function, even though $x was not a
defined variable outside the function??

~Jason

Todd Ruth

22 years ago

You can avoid the E_NOTICE using a reference, but it can have undesired
side effects.  For example, if you pass $x[5] by reference (whether to
an internal function or a user defined function), $x[5] will be
"created" and set to NULL.  To avoid this side-effect, don't use the
reference and instead use @$x[5] as the first argument to the function.
(but DO NOT use @$x[5] as an argument to a function that takes a
reference - it may cause a crash/corruption later.)

- Todd

On Thu, 2004-04-15 at 13:14, Jason Garber wrote:

Sean Coates

22 years ago

Jason Garber wrote:

> function setor(&$param, $default)
> {
>     return (isset($param) ? $param : $default);
> }
>
> I tested it on 4.3.4 and 5.0 RC1, and it worked.  Is passing an
> undefined variable as a reference parameter a legal thing to do in PHP?

That bring up an interesting point:

error_reporting(E_ALL);
function test_func(&$oink)
{
echo $oink;
}
test_func($moo);


executing this block does not fire an E_NOTICE.

S

Andrey Hristov

22 years ago

Sean Coates wrote:

> Jason Garber wrote:
>
>> function setor(&$param, $default)
>> {
>>     return (isset($param) ? $param : $default);
>> }
>>
>> I tested it on 4.3.4 and 5.0 RC1, and it worked.  Is passing an
>> undefined variable as a reference parameter a legal thing to do in PHP?
>
>
> That bring up an interesting point:
>
> error_reporting(E_ALL);
> function test_func(&$oink)
> {
>   echo $oink;
> }
> test_func($moo);
>
>
> executing this block does not fire an E_NOTICE.
>
> S
>

So, how I see the code:
inside the function you have already a variable named $oink so there won't be a E_NOTICE
for unknown var. The variable is "linked" to somewhere outside but that doesn't matter.
I think it has in common with the unset() behaviour on variables visible with "global"
keyword.

Andrey

Andi Gutmans

22 years ago

At 02:21 PM 4/15/2004 -0400, Sean Coates wrote:

>Andi Gutmans wrote:
>>It could be implemented but I don't see the big advantage over $bar ? 0 :
>>$base
>>It's one character...
>>oes to GCC and its C extension).
>>>>     $bar ? : $baz;
>>>>     If $bar evaluates to true, the expression evaluates to $bar
>>>>     or to 0, respectively.
>>>>I think we're unclear on this..
>
>What seems right to me:
>
><?php
>
>$variable = $foo ?: $bar;
>
>// is the same as
>
>if ($foo) $variable = $foo; else $variable = $bar;
>
>?>

I have to read closer next time. Personally I prefer finding a user-land
solution and not a new syntax. All these "weird" operators look like all of
the weird Perl stuff.

Andi

Sascha Schumann

22 years ago

On Fri, 16 Apr 2004, Andi Gutmans wrote:

> At 02:21 PM 4/15/2004 -0400, Sean Coates wrote:
> >Andi Gutmans wrote:
> >>It could be implemented but I don't see the big advantage over $bar ? 0 :
> >>$base
> >>It's one character...
> >>oes to GCC and its C extension).
> >>>>     $bar ? : $baz;
> >>>>     If $bar evaluates to true, the [whole] expression evaluates to $bar
> >>>>     or to [$baz], respectively.

(I had a zero in my example, changed the example, but not the
sentence.)

> >if ($foo) $variable = $foo; else $variable = $bar;

Right.

> I have to read closer next time. Personally I prefer finding a user-land
> solution and not a new syntax. All these "weird" operators look like all of
> the weird Perl stuff.

I never felt that C looks like Perl at all.  Remember that
the operator usage as proposed originates in GCC land,
because "a?:b" is a frequent usage pattern - at least in C.

- Sascha

Jason Garber

22 years ago

Hello,

Let me make an attempt to clarify what I originally requested.

------
A function/construct named setor() modeled after isset(), which takes 2
parameters:

parameter 1, the variable in question
parameter 2, the default value

if(isset($parameter1))
return $parameter1;
else
return $parameter2;

The following requirements would apply:

1. The function would not throw a notice if $parameter1 was not set
2. The second argument would not be evaluated unless it was actually needed
3. The first argument would not be modified in any way.
------

After a lengthily discussion today on the internals list, I have come to
the conclusion that this is not possible to adhere to all three of the
above requirements in user-land, but would be simple to do in internal-land.

We have more-or-less concluded that an operator would not be the way to
go.  We have also seen a general consensus that this would be a highly
helpful feature for developing in E_ALL error mode.

I'm not quite sure how the decision making process goes on in this project,
is it Andi that has the final say?

I would like to see a general consensus on:
1. Is it a feasible feature that would not interfere with the overall goals
of PHP?
2. If so, can we schedule it to be implemented in a upcoming version of PHP?
2. If not, can I pay an experienced developer to take the time to implement
it into an upcoming version of PHP?

I'm not trying to get in the way of the PHP development process, frankly,
I'm new to this side of things.  But I do have quite a few personnel on
payroll that I think would benefit significantly by having a this feature
added, which is why I would be willing to pay for it's implementation,
which in turn everyone can benefit from.


Thanks again,

Jason Garber
President
IonZoft, Inc.

Marcus Börger

22 years ago

Hello Jason,

here is your operator patch:
http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416.diff.txt

currently it uses the following syntax:

$var $: $defaul

which would equal

isset($var) ? $var : $default

Notice that at the moment the operator is '$:' and not '?:'. This is
because i haven't looked on how to solve the conflicts i get when i
use '?:'. If there is more interest in that operator i could invest
more work in trying to fix that problem.

best regards
marcus

According to your options and the possibility to implement this as a
function. That would only work as a parser internal function like empty
or set. Doing so would be very easy i guess. Though it would require a
new keyword say 'ifsetor' (which reflects its purpose more as 'setor').

best regards
marcus


Friday, April 16, 2004, 1:08:18 AM, you wrote:

> Hello,

> Let me make an attempt to clarify what I originally requested.

> ------
> A function/construct named setor() modeled after isset(), which takes 2
> parameters:

> parameter 1, the variable in question
> parameter 2, the default value

> if(isset($parameter1))
>      return $parameter1;
> else
>      return $parameter2;

> The following requirements would apply:

> 1. The function would not throw a notice if $parameter1 was not set
> 2. The second argument would not be evaluated unless it was actually needed
> 3. The first argument would not be modified in any way.
> ------

> After a lengthily discussion today on the internals list, I have come to
> the conclusion that this is not possible to adhere to all three of the
> above requirements in user-land, but would be simple to do in internal-land.

> We have more-or-less concluded that an operator would not be the way to
> go.  We have also seen a general consensus that this would be a highly
> helpful feature for developing in E_ALL error mode.

> I'm not quite sure how the decision making process goes on in this project,
> is it Andi that has the final say?

> I would like to see a general consensus on:
> 1. Is it a feasible feature that would not interfere with the overall goals
> of PHP?
> 2. If so, can we schedule it to be implemented in a upcoming version of PHP?
> 2. If not, can I pay an experienced developer to take the time to implement
> it into an upcoming version of PHP?

> I'm not trying to get in the way of the PHP development process, frankly,
> I'm new to this side of things.  But I do have quite a few personnel on
> payroll that I think would benefit significantly by having a this feature
> added, which is why I would be willing to pay for it's implementation,
> which in turn everyone can benefit from.

> Thanks again,

> Jason Garber
> President
> IonZoft, Inc.

--
Best regards,
Marcus                            mailto:helly@php.net

Marcus Börger

22 years ago

[RFC] ifsetor operator

Hello List,

i also agrre that an internal function is much better. And here is
it as such an internal function (that does not result in an expensive
function call).

Synopsis: "ifsetor" "(" value "," default ")"

Returns the value if it exists or a given default value.

Syntax:   "ifsetor" "(" variable [ "," expression ] ")"

Semantic:
- The value in question must be a variable.
- The default value can be any expression.
- The default value can be omitted in which case NULL will be used.

http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416-2.diff.txt

best regards
marcus


Friday, April 16, 2004, 2:12:04 AM, you wrote:

> Hello Jason,

> here is your operator patch:
> http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416.diff.txt

> currently it uses the following syntax:

> $var $: $defaul

> which would equal

> isset($var) ? $var : $default

> Notice that at the moment the operator is '$:' and not '?:'. This is
> because i haven't looked on how to solve the conflicts i get when i
> use '?:'. If there is more interest in that operator i could invest
> more work in trying to fix that problem.

> best regards
> marcus

> According to your options and the possibility to implement this as a
> function. That would only work as a parser internal function like empty
> or set. Doing so would be very easy i guess. Though it would require a
> new keyword say 'ifsetor' (which reflects its purpose more as 'setor').

> best regards
> marcus

[...]

Christian Schneider

22 years ago

Marcus Boerger wrote:

> [RFC] ifsetor operator
>
> Synopsis: "ifsetor" "(" value "," default ")"
>   Returns the value if it exists or a given default value.
> Syntax:   "ifsetor" "(" variable [ "," expression ] ")"
> Semantic:
>   - The value in question must be a variable.

I'd prefer to not have this restriction, a return value from a function
call should be fine. I'd make this any expression.

>   - The default value can be any expression.
>   - The default value can be omitted in which case NULL will be used.

I'd also propose to extend this to a whole list of expressions:

"notnull" "(" expression [ "," expression ]* ")"

This would return the first expression which is not null. If all
expressions are null then null is returned.

I'm not too happy with "notnull" as a name, better suggestions are
welcome :-)

Just brainstorming: An other idea would be an operator like "|||":
$a = $a1 ||| $a2 ||| $a3;
(I didn't call it "err" or "//" to not get flamed *as* badly ;-))

- Chris

Derick Rethans

22 years ago

On Fri, 16 Apr 2004, Christian Schneider wrote:

> Marcus Boerger wrote:
> > [RFC] ifsetor operator
> >
> > Synopsis: "ifsetor" "(" value "," default ")"
> >   Returns the value if it exists or a given default value.
> > Syntax:   "ifsetor" "(" variable [ "," expression ] ")"
> > Semantic:
> >   - The value in question must be a variable.
>
> I'd prefer to not have this restriction, a return value from a function
> call should be fine. I'd make this any expression.

isset() works on a variable only too, so this behavior matches already
existing behavior.

>
> >   - The default value can be any expression.
> >   - The default value can be omitted in which case NULL will be used.
>
> I'd also propose to extend this to a whole list of expressions:

no thanks.

> Just brainstorming: An other idea would be an operator like "|||":
> $a = $a1 ||| $a2 ||| $a3;

that looks too perlish. Be happy with what we came up with now.

Derick

Christian Schneider

22 years ago

Derick Rethans wrote:

> isset() works on a variable only too, so this behavior matches already
> existing behavior.

Hmm... this brings up another idea:
Extend isset to have this behaviour. Funnily enough when I was thinking
about such a feature I wished I could call it isset. And now I realize
that we could:
Extend isset to accept multiple arguments and make it return the value
of the first non-null it any.
Backward compatible for everything but variations of the horrible
if (isset($a) === true)

This would lead to
$a = isset($b, 'default');

>>I'd also propose to extend this to a whole list of expressions:
>
> no thanks.

Any reasons for this? I can think of situations where you have data from
3 different sources, e.g. $_REQUEST, a DB and a default:
$a = isset($_REQUEST['value'], $DB->get('value'), 'default');

> that looks too perlish. Be happy with what we came up with now.

That doesn't look perlish, it *is* Perl. Perl 6 actually (-:C
But now that I thought of isset() I have no desire for an operator any
more...

- Chris

Derick Rethans

22 years ago

On Fri, 16 Apr 2004, Marcus Boerger wrote:

> [RFC] ifsetor operator
>
> Hello List,
>
>   i also agrre that an internal function is much better. And here is
> it as such an internal function (that does not result in an expensive
> function call).
>
> Synopsis: "ifsetor" "(" value "," default ")"

<snip>

I don't like this name though, the rest sounds ok.

Other possibilities:

ifset
default

I don't like a new short-cut operator either; it doesn't fit in the
spirit of PHP IMO.

regards,
Derick

Wez Furlong

22 years ago

Derick wrote:

> I don't like this name though, the rest sounds ok.

Me either, but can't think of anything better (well, ?:
operator is good ;)

> Other possibilities:
>
> ifset
> default

default is already used in switch

--Wez.

Hans Juergen von Lengerke

22 years ago

In the hope that joining the discussion as a non-developer
isn't considered rude behaviour...

> Wez wrote:
> Derick wrote:
> > Other possibilities:
> >
> > ifset
> > default
>
> default is already used in switch

Just another idea for you internals guys:

$foo = firstset($bar, $baz [, $quux [, ...]]);

Assigns the first isset arg to $foo.

This would make one nice use of Sascha's GCC style
suggestion possible:

$foo = $bar ?: $baz ?: $quux;

But personally, I would prefer the GCC style syntax.

Hans

J Smith

22 years ago

Derick Rethans wrote:

> On Fri, 16 Apr 2004, Marcus Boerger wrote:
>
>> [RFC] ifsetor operator
>>
>> Hello List,
>>
>>   i also agrre that an internal function is much better. And here is
>> it as such an internal function (that does not result in an expensive
>> function call).
>>
>> Synopsis: "ifsetor" "(" value "," default ")"
>
> <snip>
>
> I don't like this name though, the rest sounds ok.
>
> Other possibilities:
>
> ifset
> default
>
> I don't like a new short-cut operator either; it doesn't fit in the
> spirit of PHP IMO.
>
> regards,
> Derick

doesn't this function sort of work like the SQL function coalesce()? in SQL
(SQL92, i think?) coalesce() takes any number of arguments and returns the
first one that isn't NULL and returns NULL if everything is NULL. would
that sort of fit in here?

even if the name doesn't fit, that might actually be a useful addition, to
let the function accept any number of parameters and return the first one
that isn't NULL or the first one that has already been set.

J

Wez Furlong

22 years ago

It's worth nothing that, if T_IFSETOR was recognized by the
scanner as "?:", then Sascha/GCC "?:" operator is also implemented
by this patch, by changing the parser rule from this:

T_IFSETOR '(' variable ',' expr ')'

to this:

T_IFSETOR variable ':' expr

--Wez.


----- Original Message -----
From: "Marcus Boerger" <helly@php.net>
To: <internals@lists.php.net>
Cc: "Jason Garber" <jason@ionzoft.com>; "Andi Gutmans" <andi@zend.com>
Sent: Friday, April 16, 2004 8:38 PM
Subject: [PHP-DEV] [RFC] ifsetor operator

Wez Furlong

22 years ago

George just pointed out that this isn't quite right :)
The point is that we've got the guts, it's just a few tweaks
to get it into the parser.

--Wez.

----- Original Message -----
From: "Wez Furlong" <wez@thebrainroom.com>
To: "Marcus Boerger" <helly@php.net>; <internals@lists.php.net>
Cc: "Jason Garber" <jason@ionzoft.com>; "Andi Gutmans" <andi@zend.com>
Sent: Friday, April 16, 2004 9:19 PM
Subject: Re: [PHP-DEV] [RFC] ifsetor operator

> It's worth nothing that, if T_IFSETOR was recognized by the
> scanner as "?:", then Sascha/GCC "?:" operator is also implemented
> by this patch, by changing the parser rule from this:
>
> T_IFSETOR '(' variable ',' expr ')'
>
> to this:
>
> T_IFSETOR variable ':' expr
>
> --Wez.
>
>
> ----- Original Message -----
> From: "Marcus Boerger" <helly@php.net>
> To: <internals@lists.php.net>
> Cc: "Jason Garber" <jason@ionzoft.com>; "Andi Gutmans" <andi@zend.com>
> Sent: Friday, April 16, 2004 8:38 PM
> Subject: [PHP-DEV] [RFC] ifsetor operator
>
>
> > [RFC] ifsetor operator
> >
> > Hello List,
> >
> >   i also agrre that an internal function is much better. And here is
> > it as such an internal function (that does not result in an expensive
> > function call).
> >
> > Synopsis: "ifsetor" "(" value "," default ")"
> >
> >   Returns the value if it exists or a given default value.
> >
> > Syntax:   "ifsetor" "(" variable [ "," expression ] ")"
> >
> > Semantic:
> >   - The value in question must be a variable.
> >   - The default value can be any expression.
> >   - The default value can be omitted in which case NULL will be used.
> >
> > http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416-2.diff.txt
> >
> > best regards
> > marcus
> >
> >
> > Friday, April 16, 2004, 2:12:04 AM, you wrote:
> >
> > > Hello Jason,
> >
> > > here is your operator patch:
> > > http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416.diff.txt
> >
> > > currently it uses the following syntax:
> >
> > > $var $: $defaul
> >
> > > which would equal
> >
> > > isset($var) ? $var : $default
> >
> > > Notice that at the moment the operator is '$:' and not '?:'. This is
> > > because i haven't looked on how to solve the conflicts i get when i
> > > use '?:'. If there is more interest in that operator i could invest
> > > more work in trying to fix that problem.
> >
> > > best regards
> > > marcus
> >
> > > According to your options and the possibility to implement this as a
> > > function. That would only work as a parser internal function like

empty

> > > or set. Doing so would be very easy i guess. Though it would require a
> > > new keyword say 'ifsetor' (which reflects its purpose more as

'setor').

George Schlossnagle

22 years ago

I vote for nvl(), as the oracle pl/sql function of the same name has
this exact semantic.


On Apr 16, 2004, at 4:19 PM, Wez Furlong wrote:

> It's worth nothing that, if T_IFSETOR was recognized by the
> scanner as "?:", then Sascha/GCC "?:" operator is also implemented
> by this patch, by changing the parser rule from this:
>
> T_IFSETOR '(' variable ',' expr ')'
>
> to this:
>
> T_IFSETOR variable ':' expr
>
> --Wez.
>
>
> ----- Original Message -----
> From: "Marcus Boerger" <helly@php.net>
> To: <internals@lists.php.net>
> Cc: "Jason Garber" <jason@ionzoft.com>; "Andi Gutmans" <andi@zend.com>
> Sent: Friday, April 16, 2004 8:38 PM
> Subject: [PHP-DEV] [RFC] ifsetor operator
>
>
>> [RFC] ifsetor operator
>>
>> Hello List,
>>
>>   i also agrre that an internal function is much better. And here is
>> it as such an internal function (that does not result in an expensive
>> function call).
>>
>> Synopsis: "ifsetor" "(" value "," default ")"
>>
>>   Returns the value if it exists or a given default value.
>>
>> Syntax:   "ifsetor" "(" variable [ "," expression ] ")"
>>
>> Semantic:
>>   - The value in question must be a variable.
>>   - The default value can be any expression.
>>   - The default value can be omitted in which case NULL will be used.
>>
>> http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416-2.diff.txt
>>
>> best regards
>> marcus
>>
>>
>> Friday, April 16, 2004, 2:12:04 AM, you wrote:
>>
>>> Hello Jason,
>>
>>> here is your operator patch:
>>> http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416.diff.txt
>>
>>> currently it uses the following syntax:
>>
>>> $var $: $defaul
>>
>>> which would equal
>>
>>> isset($var) ? $var : $default
>>
>>> Notice that at the moment the operator is '$:' and not '?:'. This is
>>> because i haven't looked on how to solve the conflicts i get when i
>>> use '?:'. If there is more interest in that operator i could invest
>>> more work in trying to fix that problem.
>>
>>> best regards
>>> marcus
>>
>>> According to your options and the possibility to implement this as a
>>> function. That would only work as a parser internal function like
>>> empty
>>> or set. Doing so would be very easy i guess. Though it would require
>>> a
>>> new keyword say 'ifsetor' (which reflects its purpose more as
>>> 'setor').
>>
>>> best regards
>>> marcus
>>
>> [...]
>>
>> --
>> 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
>
>

// George Schlossnagle
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth

Marcus Börger

22 years ago

Friday, April 16, 2004, 10:36:55 PM, you wrote:

> I vote for nvl(), as the oracle pl/sql function of the same name has
> this exact semantic.

Hello George,

that's avery good idea!

it is to weird to have a lot of people using this already. And a lot of
people would expect the exact behavior by its name. Jus because it exists
elsewhere and there a l ot of people use it.

marcus

Hartmut Holzgraefe

22 years ago

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>

Wez Furlong

22 years ago

+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