detect closure in __sleep to prevent their serialization - php

When I'm trying to serialize an object which has members including closures an exception is thrown.
To avoid the serialization of the members including closures I tried the following:
function __sleep(){
$ref = new ReflectionClass($this);
$props = $ref->getProperties();
foreach ($props as $prop){
$name = $prop->name;
if (is_callable($this->$name)===false){
$dream[] = $prop->name;
}
}
return $dream;
}
Unfortunately this does not work. Is there a better way to detect whether a property is a closure or not.
EDIT: I solved my problem by letting the closure know whether to serialize or not
To do this I am wrapping the closure itself. Here's an example:
/**
* Wrapper-class to prevent closure to be serialized.
*/
class WrappedClosure {
private $closure = NULL;
protected $reflection = NULL;
public function __construct($function){
if ( ! $function instanceOf Closure)
throw new InvalidArgumentException();
$this->closure = $function;
$this->reflection = new ReflectionFunction($function);
}
/**
* When the instance is invoked, redirect invocation to closure.
*/
public function __invoke(){
$args = func_get_args();
return $this->reflection->invokeArgs($args);
}
// do nothing on serialization
public function __sleep(){}
// do nothing on serialization
public function __wakeup(){}
}
// Assigning a wrapped closure to a member
$myObject->memberHoldingAClosure =
// Wrapping the closure
new WrappedClosure(
function (){
echo "I'am the inner closure.";
}
)
);
// the serialization doesn't throw an exception anymore
serialize($myObject);

Works fine for me:
class foo {
protected $param = 'value';
protected $closure = null;
public function __construct() {
$this->closure = function(){
return 123;
};
}
public function __sleep() {
$serializable = array();
foreach ( $this as $paramName => $paramValue ) {
if ( !is_string($paramValue) && !is_array($paramValue) && is_callable($paramValue) ) {
continue;
}
$serializable[] = $paramName;
}
return $serializable;
}
}
$foo = new foo();
echo serialize($foo);
About checking if value is instance of Closure class (from manual):
Anonymous functions are currently
implemented using the Closure class.
This is an implementation detail and
should not be relied upon.
Therefore I would implement is_closure($value) function as return !is_string($value) && !is_array($value) && is_callable($value) rather than return $value instanceof Closure and hope that some day PHP developers will add native is_closure() function.

Honestly, I think you're trying to solve the wrong problem. If you're sleeping the class, then isn't it wrong to have a successful sleep if you can't serialize everything? Otherwise you can wake up to an inconsistent state (or at least a state that's different than the current one). So I would argue that you should just put everything into the resultant array and then let PHP tell you if it's not serializable.
Otherwise, do you then need to check to see if any stored objects are serialzable? Should you then be checking for Serializable interface or the existence of __sleep? Where do you draw the line? So I would say that you should only not serialize resources and variables that you explicitly know how to recreate in the wakeup function (such as a database connection, or any closures you explicitly know how to recreate). But be careful here, since if you let those closures/resources be changed via the object's API, how can you be sure of a successful wakeup to the prior state.
So in short, I would recommend just returning everything, and letting PHP handle unserializable variables. Otherwise you'd need to either white-list (which isn't going to be practical) or black-list (which isn't going to be complete). And neither is a great solution. Just handle the exception when it comes (throwing and catching exceptions isn't bad).
As far as your exact question, I would implement it as follows:
function is_closure($callback) {
$func = function(){};
return $callback instanceof $func;
}
It still relies on the implementation detail of the closure being of a Object type, but I think that's the best we can do at this point. The best solution would be to petition the core to add a is_closure() function which would be implementation independent...

Related

PHP combining 2 classes where 1 can be optional with composition [duplicate]

This question already has answers here:
Is there a "nullsafe operator" in PHP?
(3 answers)
Closed 2 years ago.
I would like to combine 2 objects through composition with one optional object and keep a generic and clean API. To provide an example:
class Composition implements Object1Interface, Object2Interface
{
private $object1;
private $object2;
public function __construct($object1, $object2 = null)
{
$this->$object1 = $object1;
$this->$object2 = $object2;
}
// This will always work since the object is mandatory.
public function getId() {
return $this->object1->getId();
}
// This may fail because the object2 can be null.
public function getName() {
return $this->object2->getName();
}
}
You could see that this starts to fail pretty fast since I could be proxying on a null object here. What would be a good way to solve this?
If I were to make $object2 mandatory while I might not have all the constructor data at all times to fill out $object2, I need to make all arguments for the constructor optional. This seems like a big no-no since it would no longer have required arguments.
An option would be to create a method to return $object2 but this requires chaining by a user like so:
$composition->getObject2()->getName()
This could be acceptable but I am destroying the clean API that I have and am now chaining methods.
Is there anything that can be done here to fix this or should I simply go with the mentioned chaining of methods solution?
I guess you mean something like null-safe operator.
Unlike Hack, the PHP does not have this operator (the relevant RFC), so you need explicitly check the values for null. Also you can use something like Option Type. At least you can dynamically create "default" versions of dependent objects:
class Composition implements Object1Interface, Object2Interface
{
private $object1;
// ...
public function __construct(Object1Interface $object1 = null, Object2Interface $object2 = null)
{
if ($object1 !== null) {
$this->object1 = $object1;
} else {
$this->object1 = new class implements Object1Interface
{
public function getId()
{
return null;
}
};
}
// ...
}
public function getId() {
return $this->object1->getId(); // Always works.
}
}
You have two options: Either always check if the object is set before returning anything from it, or use a "dummy" object in place of a user-supplied one if one isn't supplied.
The former can become quite messy as you have to add guards around everything, so I'd personally prefer the latter.
One thing that will make implementing the latter a lot simpler is using an interface to specify the specifications of the expected object and having your constructor instantiate the dummy object if no real object is supplied.
interface AThingThatDoesSomething
{
public function getValue() : integer
}
class RealClass implements AThingThatDoesSomething
{
public function getValue() : integer
{
return mt_rand();
}
}
class DummyClass implements AThingThatDoesSomething
{
public function getValue() : integer
{
// You could return a dummy value here, or throw an exception, or whatever you deem to be the correct behaviour for the dummy class. This implementation just returns 0 for simplicity
return 0;
}
}
class ConsumingClass
{
private $requiredInstance = null;
private $optionalInstance = null;
public function __construct(AThingThatDoesSomething $requiredInstance, AThingThatDoesSomething $optionalInstance = null)
{
if (null === $optionalInstance)
{
$optionalInstance = new DummyClass();
}
$this->requiredInstance = $requiredInstance;
$this->optionalInstance = $optionalInstance;
}
public function getRequiredVal() : integer
{
return $this->requiredInstance->getValue();
}
// You don't need to worry if the user supplied an optional instance here because if they didn't then the dummy instance will have been instantiated instead
public function getOptionalVal() : integer
{
return $this->optionalInstance->getValue();
}
}
This might seem like a contrived example, and of course you'd be right, but it also demonstrates one of the benefits of a pattern called Design By Contract. As long as an object promises to meet certain criteria (in this case by implementing an interface) then you can substitute any object that meets those criteria, even if the object doesn't actually do anything.
In real life I use this for classes where I need logging. I use the psr\log package and set a new NullLogger in the constructor. If I need actual logging I then use setLogger() to pass a logger in, but if I don't then I don't need to worry about $this->logger failing because it's always set.

Binding a closure to a class as a new method

I am building an API class that extends the functionality of a vendor class. The vendor class expects to be extended, and will check for the existence of methods like this:
if (method_exists($this, 'block'.$CurrentBlock['type']))
{
$CurrentBlock = $this->{'block'.$CurrentBlock['type']}($CurrentBlock);
}
So since my API is also a vendor file, I thought I'd do something clever and try to let people pass closures into my API and have that extend the class.
public function extendBlock($blockName, Closure $closure)
{
$methodName = camel_case("block_{$blockName}");
$this->{$methodName} = $closure;
return method_exists($this, $methodName);
}
This would theoretically bind the closure so that the call in my first codeblock would succeed... but that doesn't happen. It is not seen as a method, but rather a property which contains a closure. Not only does method_exist fail, but attempting to call the method fails.
Here's a modified version where I'm trying to figure out what's going wrong.
public function extendBlock($blockName, Closure $closure)
{
$methodName = camel_case("block_{$blockName}");
$newClosure = clone $closure;
$newClosure = $newClosure->bindTo($this);
$this->{$methodName} = $newClosure;
$this->{$methodName}();
return method_exists($this, $methodName);
}
None of this works. The property is definitely set and the scope for $this in $closure is currently pointing to the $this of that method.
If I run this instead, the closure executes correctly.
$this->{$methodName} = $newClosure;
//$this->{$methodName}();
$foobar = $this->{$methodName};
$foobar();
So yeah. I was really hoping for a nice, tidy way of satisfying the check in my first codeblock without requiring the user to inherit my class and write them directly, but I don't think that's possible.
Edit: This is slightly different from Storing a Closure Function in a Class Property in PHP -- while the solution with __call that was provided there is excellent and is worth looking into if you're curious about binding closures to a class, this method does not trick the method_exists check.
It will not work with method_exists() as that function provides information based on methods which are declared explicitly in the class scope. However, there is still workaround with magic methods. __call() to be precise:
class Caller
{
public function bind($method, Closure $call)
{
$this->$method = $call;
}
public function __call($method, $args)
{
if (isset($this->$method) && $this->$method instanceof Closure) {
return call_user_func_array($this->$method, $args);
}
}
}
Will allow you to force call on your "property callable". For example,
$c = function($x) {
return $x*$x;
};
$obj = new Caller();
$obj->bind('foo', $c);
var_dump($obj->foo(4)); //16
See sample here.
There may be ways to change the class itself dynamically (runkit and company), but I would strongly recommend to stay away from that as long as possible.
With latest Runkit from http://github.com/zenovich/runkit you can simply write runkit_method_add(get_class($this), $methodName, $newClosure);
to do this.

How to use reusable validation in a ValueObject

I'm trying to get my head around combining some techniques.
It seems good practice to never make it possible to create a ValueObject that is not valid. The ValueObject constructor therefor should fail whenever the provided content is not good enough to create a valid ValueObject. In the examples I have, an EmailAddress object can only be created when there is a value present. So far, so good.
Validating the value of the provided emailaddress, that's where I begin to doubt the principles. I have four examples, but I can't tell which one should be considered the best practice.
Example 1 is the easy one: simply a construct function, a required parameter "value", and a separate function validate to keep the code clean. All the validation code stays inside the class, and will never be available to the outside world. The class has only one purpose: store the emailaddress, and make sure it will never be an invalid one. But the code will never be reusable - I create an object with it, but that's all.
public function __construct ($value)
{
if ( $this->validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
protected function validate ($value)
{
return is_string($value); // Wrong function, just an example
}
Example 2 makes the validate function a static function. The function will never change the state of the class, so it is a correct use of the static keyword, and the code in it will never be able to change anything to any instance created from the class embedding the static function. But if I want to reuse the code, I can call the static function. Still, this feels dirty to me.
public function __construct ($value)
{
if ( $self::validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
public static function validate ($value)
{
return is_string($value); // Wrong function, just an example
}
Example 3 introduces another class, hardcoded inside the body of my object. The other class is a validation class, containing the validation code, and creates thus a class that can be used whenever and wherever I need a validation class. The class itself is hardcoded, which also means that I create a dependency on that validation class, which should be always nearby, and is not injected through dependency injection. One could say that having a validator hard coded is as bad as having the complete code embedded in the object, but on the other hand: DI is important, and this way one has to create a new class (extending, or simply rewriting) to simply change the dependency.
public function __construct ($value)
{
if ( $this->validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
protected function validate ($value)
{
$validator = new \Validator();
return $validator->validate($value);
}
Example 4 uses the validator class again, but puts it in the constructor. My ValueObject thus needs a validator class already present and created, before creating the class, but it is possible to easily overwrite the validator. But how good is it for a simple ValueObject class to have such a dependency in the constructor, as the only thing really important is the value, it should not be my concern to know how and where to handle if the email is correct, and providing a correct validator.
public function __construct ($value, \Validator $validator)
{
if ( $validator->validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
The last example I started thinking about, is providing a default validator, and meanwhile make it possible to inject through DI an overwrite for the validator in the constructor. But I started doubting how good a simple ValueObject is when you overwrite the most important part: the validation.
So, anyone has an answer which way one should best write this class, that is correct for something as easy as an emailaddress, or something more complex like a barcode or a visa card or whatever one may think about, and doesn't violate DDD, DI, OOP, DRY, wrong use of static, and so on...
The complete code:
class EmailAddress implements \ValueObject
{
protected $value = null;
// --- --- --- Example 1
public function __construct ($value)
{
if ( $this->validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
protected function validate ($value)
{
return is_string($value); // Wrong function, just an example
}
// --- --- --- Example 2
public function __construct ($value)
{
if ( $self::validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
public static function validate ($value)
{
return is_string($value); // Wrong function, just an example
}
// --- --- --- Example 3
public function __construct ($value)
{
if ( $this->validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
protected function validate ($value)
{
$validator = new \Validator();
return $validator->validate($value);
}
// --- --- --- Example 4
public function __construct ($value, \Validator $validator)
{
if ( $validator->validate($value) )
{
throw new \ValidationException('This is not an emailaddress.');
}
$this->value = $value;
}
}
Example 4!
Why? Because it's testable, plain and simple.
Depending on what your validator actually does (in some circumstances your validator may rely on an API call or a call to a database) the injectable validator is completely testable via mocks. All of the other's are either impossible to test under the circumstances I just mentioned, or incredibly hard to test.
EDIT: For those wondering how the dependency injection method helps with testing then consider the CommentValidator class below that utilises a standard Akismet spam checking library.
class CommentValidator {
public function checkLength($text) {
// check for text greater than 140 chars
return (isset($text{140})) ? false : true;
}
public function checkSpam($author, $email, $text, $link) {
// Load array with comment data.
$comment = array(
'author' => $author,
'email' => $email,
'website' => 'http://www.example.com/',
'body' => $text,
'permalink' => $link
);
// Instantiate an instance of the class.
$akismet = new Akismet('http://www.your-domain.com/', 'API_KEY', $comment);
// Test for errors.
if($akismet->errorsExist()) { // Returns true if any errors exist.
if($akismet->isError('AKISMET_INVALID_KEY')) {
return true;
} elseif($akismet->isError('AKISMET_RESPONSE_FAILED')) {
return true;
} elseif($akismet->isError('AKISMET_SERVER_NOT_FOUND')) {
return true;
}
} else {
// No errors, check for spam.
if ($akismet->isSpam()) {
return true;
} else {
return false;
}
}
}
}
And now below, when you're setting up your unit tests we have a CommentValidatorMock class that we use instead, we have setters to manually change the 2 output bools we can have, and we have the 2 functions from above mock'd up to output whatever we want without having to go through the Akismet API.
class CommentValidatorMock {
public $lengthReturn = true;
public $spamReturn = false;
public function checkLength($text) {
return $this->lengthReturn;
}
public function checkSpam($author, $email, $text, $link) {
return $this->spamReturn;
}
public function setSpamReturn($val) {
$this->spamReturn = $val;
}
public function setLengthReturn($val) {
$this->lengthReturn = $val;
}
}
If you're serious about unit testing then you need to use DI.
The first instinct is usually the best. You should use the first option. EmailAddress is a value object. It can be reused in other value objects or entities. I don't understand why you think it's not reusable. You can have a "shared library" of these common value objects used in other bounded contexts. Just be careful what you put in there. They would need to be truly generic if that's even conceptually possible.
I think if you use separate validation methods or move the validators to separate class will be butter and prevent DRY
class EmailAddress{
protected $value;
public function __construct ($value)
{
$this->value = \validateEmailAddress($value);
}
}
function validateEmailaddress(string $value) : string
{
if(!is_string($value)){
throw new \ValidationException('This is not an emailaddress.');
} // Wrong function, just an example
return $value;
}
//OR for strict OOP people
final class VOValidator{
private function __construct(){}
public static function validateEmailaddress(string $input): string{...}
}
//I will prefer even go far and use Either from (FP monads)
interface ValueObejctError {}
class InvalidEmail implements ValueObjectError {}
function validateEmailaddress(string $input): Either {
// it will be better if php supported generic so using Either<InvalidaEmail, string> is more readable but unfortunately php has no generic types, maybe in future
return is_string($input)
? new Right($input)
: new Left(new InvalidEmail());
}

Choose the instance upon unserialization

I'm writing a PHP class similar to Java's Currency:
The class is designed so that there's never more than one Currency instance for any given currency. Therefore, there's no public constructor. You obtain a Currency instance using the getInstance methods.
It's fairly easy with PHP to keep a static array of instantiated objects, and perform a lookup in getInstance() to return an existing instance, or instantiate it if needed.
The problem comes with serialization. Even if I implement Serializable, I have no way to choose the instance I want to return in unserialize(), as the object is already instantiated at this point, and because in PHP you cannot override $this:
class Currency implements Serializable
{
public function getInstance()
{
// ...
}
public function serialize()
{
// ...
}
public function unserialize($data)
{
// At this point, the object is already instantiated,
// so I can't just return self::getInstance(),
// and can't override $this
}
}
Is there any technical solution to choose the instance to return upon unserialization?
-- edit --
This is the use case I'm trying to solve:
$euro = Currency::getInstance('EUR');
assert($euro === unserialize(serialize($euro));
I know that I can build a similar object with unserialize(), but I'm wondering if it's ever possible to get the same object.
td;dr; No, you can't do this natively in PHP, because unserialize() doesn't support the same readResolve() functionality as Java does.
In Java, on deserialization, a new instance of an object is created, its state is restored, then readResolve() is invoked on the class, if it exists. readResolve() takes the newly created deserialized object, then resolves it to another object (if needed), at which point the resolved object is what's returned from deserialization. The new instance that was originally created is left to be garbage collected if readResolve() returned a different object than the one that was supplied to it.
In PHP, there is no such hook within unserialize(). You can implement a workaround, however, define your own resolve method to emulate readResolve(), but you would be required to call it after unserialize().
class Currency implements Serializable {
private $currencyCode;
private static $instances = array();
private function __construct( $currencyCode) {
$this->currencyCode = $currencyCode;
}
public static function getInstance( $currencyCode) {
if( !isset( self::$instances[$currencyCode])) {
self::$instances[$currencyCode] = new Currency( $currencyCode);
}
return self::$instances[$currencyCode];
}
public function serialize() {
return serialize( $this->currencyCode);
}
public function unserialize( $data) {
$this->currencyCode = unserialize( $data);
}
public static function resolve( $obj) {
$new = self::getInstance( $obj->currencyCode);
if( $new !== $obj) {
unset( $obj);
}
return $new;
}
}
$euro = Currency::getInstance('EUR');
assert($euro === Currency::resolve( unserialize(serialize($euro))));
Of course, there is nothing stopping somebody from not calling Currency::resolve(), and you will then end up with more than one object for the given currency code.

Avoiding conditionals in lazy loading

Just to clarify, I mean something like:
class foon {
private $barn = null;
public function getBarn() {
if (is_null($this->barn)) {
$this->barn = getBarnImpl();
}
return $this->barn;
}
}
This is especially nice when you don't always need getBarn, and getBarn is particularly expensive (e.g. has a DB call). Is there any way to avoid the conditional? This takes up a lot of space, looks ugly, and seeing conditionals disappear is always nice. Is there some other paradigm to handle this lazy loading that I just can't see?
By using php's __call() magic method, we can easily write a decorator object that intercepts all method calls, and caches the return values.
One time I did something like this:
class MethodReturnValueCache {
protected $vals = array();
protected $obj;
function __construct($obj) {
$this->obj = $obj;
}
function __call($meth, $args) {
if (!array_key_exists($meth, $this->vals)) {
$this->vals[$meth] = call_user_func_array(array($this->obj, $meth), $args);
}
return $this->vals[$meth];
}
}
then
$cachedFoon = new MethodReturnValueCache(new foon);
$cachedFoon->getBarn();
I've wondered this from time to time, but I certainly can't think of one. Unless you want to create a single function to handle this with arrays and reflective property lookups.
You could do:
return $this->barn != null ? $this->barn : ($this->barn = self::getBarnImpl());
But I don't see how that's any better.
return ( $this->barn = $this->barn ? $this->barn : getBarn() );
or the php 5.3 (?) one:
return ( $this->barn = $this->barn ?: getBarn() );
I don't think I have ever seen a method for completely eliminating this type of lazy initialization checking, but it is interesting to think about. With a toy sample there doesn't seem to be any advantage, but in large objects you could refactor the lazy initialization behavior into either the object to be initialized or (more interestingly) some sort of generic lazy initializer pattern (I am picturing something roughly similar to a singleton). Basically unless they decide to build it in as a language construct (in which case it would still be there, only hidden) I think the best you can do is to encapsulate the code yourself.
class LazyObject
{
...
public function __construct($type, $args)
{
$this->type = $type;
...
}
public getInstance()
{
if (empty($this->instance))
$this->instance = new $this->type($args);
return $instance;
}
}
class AggregateObject
{
private $foo;
private $bar;
public function __construct()
{
$this->foo = new LazyObject('Foo');
$this->bar = new LazyObject('Bar');
}
public function getFoo()
{
return $this->foo->getInstance();
}
...
}
Method1
I can think of listener class.
Constructor () {
object = null
listener = new Object() { // this is called once
object = init()
listener = new Object() { // next time
do-nothing() // this is called
}
}
Object get() {
listener.invoke()
return object
This has no condition checkers but it adds an extra field to every object, effectively duplicaing the memory consumption whereas the stupid penalty of calling useless code, listener.invoke(), persists. I do not know how to remove it with all the polymorphysm. Because the get() method is shared by all instances of the class, it cannot be morphed.
Method2
Java on-demand initialization by exploiting the lazy class loading.
Bottom line
So, it looks like the alternatives are worse than the conditional because modern CPUs optimize the branch predictions. So, check penalty will be very tiny, I expect, once code is initialized and branch is always go into one direction. The false branch will be taken only once, at the initialization time, and it will also be short compared to your initialization time. Otherwise you may be do not want to defer the initialization.

Categories