Re: [PHP] Generic decorators and type hinting
Is there another way to cleanly wrap method calls for timing/logging purposes? I have a possibly-evil idea that gets around type-hinting by dynamically declaring decorator classes as children of the real classes that need to be timed. You end up with as many decorators as you have classes that need to be timed, but if this is for dev/QA purposes only, that might not be a problem. This method can't have the conceptual simplicity of yours, unfortunately, because __call() will never be invoked in a child class. The original parent's methods will just be called instead. But you can still override the parent's methods with wrapper methods in the child class. I've got some sample code written that first calls get_class_methods() to list the names of all the visible methods of the parent object, then constructs code to declare a child class that overrides those methods with wrapper methods, and finally eval()s the declaration and instantiates an object of the new class. The basic concept seems to work and to get along fine with type-hinting. I'm happy to share the test code if you're interested. Not sure how it would end up working in real life, and I'm guessing there are more sophisticated ways to achieve the same concept, perhaps using the Reflection API. I suspect it also needs some refining to handle protected methods. But it might be a start. Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Generic decorators and type hinting
On Sep 2, 2009, at 12:17 PM, Ben Dunlap wrote: I've got some sample code written that first calls get_class_methods() to list the names of all the visible methods of the parent object, then constructs code to declare a child class that overrides those methods with wrapper methods, and finally eval()s the declaration and instantiates an object of the new class. You're right; that is evil. But, interesting idea. It turns out for my specific purposes (a generic decorator that measures a class's method execution times), a full-fledged profiler like APD is really what I need, but I'll keep this in mind for getting around the type-hinting, should the need arise again. Thanks. -- David Kurtz dku...@technorati.com
Re: [PHP] Generic decorators and type hinting
I have a possibly-evil idea that gets around type-hinting by
dynamically declaring decorator classes as children of the real
classes that need to be timed. You end up with as many decorators as
you have classes that need to be timed, but if this is for dev/QA
purposes only, that might not be a problem.
You don't even need to do that; it'd generate way too much redundant
code. Instead, just use interfaces. The only real downside is that
all the classes you want to decorate would need to implement them and
that would cause a wee bit of ugliness in the code/class declaration.
But if you are fine with that, it's a perfect solution, particularly
since you can type hint interfaces.
interface iDecorator {}
class Thing implements iDecorator {}
class Timer
{
public static function time( iDecorator $obj ) {}
}
$obj = new Thing();
Timer::time( $obj ); // $obj becomes a Timer obj with $obj inside it
$obj-thingMethod(); // Timer passes call to Timer-obj
thnx,
Christoph
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Generic decorators and type hinting
code. Instead, just use interfaces. The only real downside is that all the classes you want to decorate would need to implement them and that would cause a wee bit of ugliness in the code/class declaration. Can you explain a bit more? As I understood the OP, the challenge was to take a large, already-built code base that relies on Zend Framework (which itself has 1600 classes), and wrap arbitrary existing methods with timing logic -- without significant code changes. As I understand your solution, it would require all pre-existing classes to be modified to implement the iDecorator interface -- and even then, pre-existing methods in those pre-existing classes would not actually be affected. So those would have to be modified also. But maybe I'm totally missing something? Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
