Req #63834 [Opn]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1 ID: 63834 Updated by: krak...@php.net Reported by:tolan333 at gmail dot com Summary:Add a function to detect a methods calling context Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: acquiring a backtrace is an inefficient means of obtaining this information ... Previous Comments: [2012-12-31 11:55:17] ni...@php.net I still fail to use just what exactly this asks for and how it would be beneficial. @krakjoe: The get_calling_method and get_calling_class functions you added should already be fully covered by debug_backtrace, so I see little value in adding them (as the use case is rather limited). @op: Regarding the last two PHP_CONTEXT_EXTERN constants, what do you mean by "user" and "core"? E.g. if you invoke a callback using call_user_func, is that an internal or a userland call? It's the internal function doing the call, but it's really the user who triggers it. I don't see how these constants would carry any meaning. The other two again can be covered by debug_backtrace, can't they? Just get the class of the call and check whether it equals __CLASS__ (=> private) or is a subclass of __CLASS__ (=> protected) or is none (=> public). Seems simple enough to me. [2012-12-31 11:49:59] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356954599 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356954599 [2012-12-31 11:37:55] krak...@php.net -2 will provide get_calling_method and get_calling_class, I think that's everything you should need [2012-12-31 11:36:48] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356953808 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808 [2012-12-31 11:19:32] krak...@php.net I think it makes sense to provide the scope which calls a method. Beyond this is application specific, I have suggested a patch that provides the name like the associated methods. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63834 -- Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [Opn]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Updated by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
-2 will provide get_calling_method and get_calling_class, I think that's
everything you should need
Previous Comments:
[2012-12-31 11:36:48] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356953808
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808
[2012-12-31 11:19:32] krak...@php.net
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [Opn]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Updated by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
Previous Comments:
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
