Edit report at https://bugs.php.net/bug.php?id=62519edit=1
ID: 62519
Comment by: j_holland at hotmail dot com
Reported by:awilliams at linkme dot com dot au
Summary:Find out about a function's call context
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The reason to expose the calling context is so that the function can confirm
it's correct:
function calculate_something($args){
if (get_calling_context() == VOID) {
print ERROR: must be called in non-void context!;
exit;
}
return do_expensive_calculation($args);
}
This might be unnecessary in your own code but it's VERY useful when writing
libraries. Perl has this function (wantarray) and I use it whenever I write
libraries.
Yes, this function can be misused, but so can most functions.
Overloading the return keyword is a terrible way to implement this. Make it a
clearly named function, like get_calling_context.
Finally, it would probably be sufficient to simply return void/non-void
context, but more specific context is known:
print function();// the RV will be evaluated as a string
$a = 3 + function(); // the RV will be treated as a number
if (function()));// the RV will be treated as a Boolean
etc.
Previous Comments:
[2012-07-12 01:51:00] johan...@php.net
You could pass an additional parameter to the function
function ($foo, $return) {
if ($return) {
return $foo;
} else {
echo $foo;
}
}
Many people would say that changing the behavior of a function from it's use
case is bad.
I'm also not sure we can implement this without adding overhead to *all*
function calls, which we won't like to do.
[2012-07-11 11:31:07] awilliams at linkme dot com dot au
I would like to present a more concrete example of why I think this would be an
elegant solution to a coding dilemma I have.
I wrote a couple of functions to generate html for select mark-up from mySql
tables and php arrays.
Some times I want to call them directly and I want then to output the html,
other times I want to use them in string expressions, in which case I want them
to return the html.
As it stands I would have to do this using different function names, which
looks messy.
To implement this I have two choices, maintain two separate functions doing
almost the same thing. That is never best practice. Sooner or later you
forget to do a change to both of them.
Declare the string returning function and call it from the string printing
version. This is wasteful of stack and call time resources, I try not to code
like that.
I am left looking at this thinking it would be a really elegant solution if the
function its self could tell what context it was called in and either echo or
return the output as required.
I agree that itâs a somewhat unconventional suggestion. I wouldn't expect it
of 'C'. I write in PHP because many things are simpler an more flexible here,
and this would definitely add a new form of flexibility that I have a use for.
Thank you and that's my last word on it.
Alan
[2012-07-10 14:01:11] ni...@php.net
PHP is a dynamically typed language. It can't in the general case know what
type is expected. Simple example if f1() + f2(). Here int, float and array
would be viable return types.
Whether the return value is used or not is known to the engine and also exposed
to internal functions.
But I don't think that it makes sense to expose it to userland functions.
Functions shouldn't behave different based on whether the return value is used
or not.
[2012-07-10 04:10:55] awilliams at linkme dot com dot au
Description:
I would like to be able to tell if a function was called from a context that is
expecting a return value or not. Additionally what type is expected.
eg('hello');// called not expecting a return value
echo eg('hello').' world'; // called expecting a string
function eg($s)
{
if(return){ // suggested overloading of the return keyword to report the
function context.
return ($s);
}
else{
echo $s;
}
}
Additionally
gettype(return);
and
is_string(return);
is_array(return);
etc
--
Edit this bug report at https://bugs.php.net/bug.php?id=62519edit=1
