using namespace kyle; - a few dilemmas

A few dilemmas

Kyle Kirby

December 16, 2011

Hello! Greetings from the comfort of my bed! Today I ran across a couple of issues that I didn't directly know the answers to. The first of my isseus was dealing with implementation classes and their interfaces. To further clarify, having an interface and an implementation of the interface. The problem that I faced is I had no idea what to name the two different classes. You have an interface that defines some sort of functionality, and then you have a class that implements the interface, being the default functionality. Now normally, I'd just use an abstract class to have both implementation and interfacing, but you can't always extends more than one class. This is why I wanted to have both. One incase you couldn't extend from the abstract class, but you wanted to define that your class can indeed do te job. After some debating and talking it over with my peers, I decided to name the interface with an "I" preceeding the class name, and the implemenation without the "I". Eg:

<?php
interface IBazz {
	public function foo();
}

abstract class Bazz implements IBazz {
	public function foo(){
		// Greetings!
	}
}
?>

So, pretty simple. But something to take note of. All of this is fine and dandy, but what was it that I was actually trying to do? Why did I want to have such specific interfaces and default implementation? Well, my goal was this: For a class to have the ability to mutate its properties from a defined map. In lamenz, being able to change properties on a class (protected or not) without having to directly do it. This helps greatly for highly-customized classes, but to make updates would cause for a major release, where-as making updates to a map would be able to go out to production with a much lower risk. Please see the example below:

<?php
interface IConfigurable {
	public function configure(array $configuration);	
}

abstract class Configurable implements IConfigurable {
	public function configure(array $configuration){
		$class = get_class($this);
		$reflection = new ReflectionClass($class);
		foreach($reflection->getProperties() as $property){
			$name = $property->name;
			if(!isset($$configuration[$name]))continue;
			$value = $configuration[$name];
			if($property->isStatic()){
				// Crazy stupid eval.
				eval(
					sprintf(
						'$var = &%s::$%s',
						$class,$name
					)
				);
				$var = $value;
			}
			else {
				$this->$name = $value;
			}
		}
	}
}

class Foo extends Configurable {
	protected $_bar = 'Yum!';
	protected static $_bizz = 'Bonns!';
	
	public function getStuff(){
		return "{$this->_bar} {self::$_bizz}";
	}
}

$bazz = new Foo;
echo $bazz->getStuff() // Yum! Bonns!
$bazz->configure(array(
	'_bar' => 'Candy!',
	'_bizz' => 'Formal!'
));
echo $bazz->getStuff(); // Candy! Formal!
?>

Hopefully this paints a pretty decent picture. I haven't tested it directly, but that's the gist. You'll notice I'm not using Reflection for setting the static variable. But a nastly eval statement. The reason for this is because you cannot do this in PHP: $class::$$name = $value; It will throw a fatal error your way! But what about: self::$$name = $value; Well yeah, that works, but only for the local scope of the abstract class. Never the child class. However, if you call the child class in the scope of the parent, you can set the static properties no problem. Like so: Foo::$_bizz = $value; This seems all crummy and what not. Am I sure PHP doesn't have a better way to do this? Well of course it does! In PHP 5.3 you can use reflection to do all the things I wanted to do; You can set parameters, public or protected, even static! But, the system I wrote the code for is not PHP 5.3, so I do not have the ability to run ReflectionProperty::setAccess(). There was one other dilemma I had, but I'm getting tired so I'll save that for next time! Happy coding/programming!