[codesyntax lang="php"]

<?php
//previously, User was defined as a DataModeller Model

$user = new User;
$user->setName('Vic Cherubini')
  ->setAge(26)
  ->setHeight(74)
  ->setJobTitle('Software Mechanic');

?>

[/codesyntax]

That’s right, it uses setters, and for the love of me, I can’t figure out why. Getters and setters, for the unaware, are something some other programming languages use to get at variables on an object. They aren’t required in PHP. The two most common reasons for using them in PHP are:

1. It allows users to set the value of private variables.
2. It allows the programmer to enforce some sanity checking on the variables when they’re set.

As for the former argument, I have no idea why you’d want to allow someone to modify a private variable and yet not make that variable public or protected instead. Maybe I’m missing something but that seems rather silly to me.

The latter argument carries a lot more weight. We all love our data integrity, for sure. But PHP provides two magic methods ( __get() and __set() ) that let you override how variables are handled by your objects. Why you wouldn’t use those… Just compare these two objects:

[codesyntax lang="php"]

<?php

class foo {
   private $bar;
   public function setBar($value) {
   	$this->bar = $value; //sanity checking here.
   }
   public function getBar($value) {
   	return $this->bar;
   }
}

class ding {
	public function __set($name, $value) {
		$this->$name = $value;
	}
	public function __get($name) {
		return $this->$name;
	}
}
?>
[/codesyntax]

Footprint-wise they’re pretty similar. You could add doc strings to foo->bar, and not to ding->bat but all in all fairly even. It’s the person using your object that’ll have a slightly easier time of it:

[codesyntax lang="php"]

<?php
//which do you like better?
$foo = new foo();
$foo->setBar('high');

$ding = new ding();
$ding->bat = "Edith Bunker";
?>

[/codesyntax]

I suppose at this point it’s six of one, a half dozen of the other. However, if you have a lot of properties and are trying to keep things DRY, there’s a clear winner:

[codesyntax lang="php"]

<?php

class foo {
   private $bar;
   private $bar2;
   private $bar3;
   private $bar4;
   private $bar5;

   public function setBar($value) {
   	$this->bar = $value; //sanity checking here.
   }
   public function getBar($value) {
   	return $this->bar;
   }
   public function setBar2($value) {
   	$this->bar2 = $value; //sanity checking here.
   }
   public function getBar2($value) {
   	return $this->bar2;
   }
   public function setBar3($value) {
   	$this->bar3 = $value; //sanity checking here.
   }
   public function getBar3($value) {
   	return $this->bar3;
   }
   public function setBar4($value) {
   	$this->bar4 = $value; //sanity checking here.
   }
   public function getBar4($value) {
   	return $this->bar4;
   }

}

class ding {
	public function __set($name, $value) {
		$this->$name = $value;
	}
	public function __get($name) {
		return $this->$name;
	}
}
?>

[/codesyntax]

So what if you want to have the utility of sanity checking your variables and phpDocumenting them, while retaining the clean and simple style of our magic methods? Well, you could put your data checks in the __set method, but that can get hairy if you’ve got a lot of variables:

[codesyntax lang="php"]

<?php

class ding {
	public function __set($name, $value) {
		if ($name == 'foo' && is_int($value)) {
			$this->foo = $value;
		} else if ($name == 'bar' && is_array($value)) {
			$this->bar = $value;
		} else if ($name == 'bat' && $value == 'Edith Bunker') {
			$this->bat = TRUE;
		}
	}
}
?>

[/codesyntax]

A better solution would be to write validator methods per data type, then suss out which type the variable being set is supposed to be, and then validate it. This looks like a job for Reflection!

[codesyntax lang="php"]

<?php
abstract class validateMe {
  protected $variableValidations;

  public function __construct() {
    if (!is_array($this->variableValidations)) {
      $this->variableValidations = $this->_getValidations();
    }
  }

  public function __set($name, $value) {
    $newName = '_'.$name;
    if ($this->_validate($newName, $value)) {
      $this->$newName = $value;
    }
  }

  public function __get($name) {
    $newName = '_'.$name;
    return $this->$newName;
  }

  protected function _validate($name, $value) {
    if (isset($this->variableValidations[$name])) {
      $validator = $this->variableValidations[$name];
      $method = $validator['type'].'Validate';
      return $this->$method($value, $validator);
    }
    return TRUE; // or FALSE if you don't want to save any variables that don't have defined validations.
  } // end _validate()

  private function _getValidations() {
    $ref = new ReflectionClass(get_class($this));
    $props = $ref->getProperties();
    $retval = array();
    foreach ($props as $prop) {
      $name = $prop->getName();
      $varType = "unknown";
      $optional = FALSE;
      $args = "";
      $doc = explode("\n",$prop->getDocComment());
      foreach ($doc as $docLine) {
        if (preg_match('/\@var\s+([A-Za-z0-9]+)\s*(.*)/', $docLine, $matches)) {
          $varType = $matches[1];
          if (preg_match('/\[optional\]\s*(.*)/', $matches[2], $submatches)) {
            $optional = TRUE;
            $args = $submatches[1];
          } else {
            $args = $matches[2];
          }
        }
      }
      $retval[$name] = array(
        'type' => $varType,
        'optional' => $optional,
        'args' => $args
      );
    }
    return $retval;
  } // end _getValidations()

}
?>

[/codesyntax]

Well, that’s nice and all, but what does it do? First, it lets you declare class properties as _propertyName but access them as propertyName. With proper doc strings, you get validation! Just write methods called <datatype>Validate (eg. stringValidate) and you’re off to the races.  Here’s an example class that extends the abstract validateMe:

[codesyntax lang="php"]

<?php
class ding extends validateMe {
  /**
   * @var array Array of options
   */
  $_options = array();

  /**
   * @var boolean [optional] Is this person a dingbat?
   */
  $_bat;

  /**
   * @var int between 10 and 100
   */
  $_number;

  public function arrayValidate($value, $options) {
    return is_array($value) || $options['optional'];
  }

  public function booleanValidate($value, $options) {
    switch ($var) {
      case $var == TRUE:
      case $var == 1:
      case strtolower($var) == 'true':
      case strtolower($var) == 'on':
      case strtolower($var) == 'yes':
      case strtolower($var) == 'y':
        $out = TRUE;
        break;
      default: $out = FALSE;
    }

    return $out || $options['optional'];
  }

  public function intValidate($value, $options) {
    if (preg_match('/between\s*(\d+)and\s*(\d+)/i', $options['args'], $matches)) {
      if (is_numeric($value)) {
        if ((int)$value == $value) {
          return ($matches[1] <= $value && $value <= $matches[2]) || $options['optional']; // is it between?
        } else {
          return FALSE || $options['optional']; // numeric, but not an integer
        }
      } else {
        return FALSE || $options['optional']; // not numeric
      }
    } else {
        return (is_numeric($value) && ((int)$value == $value)) || $options['optional'];
    }
  }
}
?>

[/codesyntax]

Now in this case, this isn’t any less verbose than the getter/setter alternative would be. But this is an example to show how crazy you could get. Here’s a more real world example, a user object:

[codesyntax lang="php"]

<?php
class user extends validateMe {
  /**
   * @var string /^[A-Za-z0-9_-]+$/ User name, alphanumerics - and _ are allowed.
   */
  private $_username;
  /**
   * @var string /^[A-Za-z]+$/ Last name, alpha allowed.
   */
  private $_surname;
  /**
   * @var string /^[A-Za-z]+$/ First name, alpha allowed.
   */
  private $_givenname;
  /**
   * @var string /^\d{3}[-]*\d{2}[-]*\d{4}$/ Social Security Number
   */
  private $_ssn;  public function stringValidate($value, $options) {
    if (preg_match('/(\/[^\/]+\/).*/', $options['args'], $matches)) {
      // we have a regex
      return (is_string($value) && preg_match($matches[1], $value)) || $options['optional'];
    } else {
      return is_string($value) || $options['optional'];
    }
  }
}
?>

[/codesyntax]

And you’ve validated and documented all of your variables, without writing individual getter/setter functions for each. Mmm… That’s a spicy meatball!

This is actually pretty close to how the new anObject is going to work. SmartObjects, though, are getting a super fancy validation plugin that does this, and also will check the DB structure for validity. “DESCRIBE `tablename`” anyone?

Exceptions and the Handling Thereof...

Ralph Schindler has an article up about the new Exception features of PHP 5.3, as well as some best practices involving Exceptions. To be honest, I hadn’t realized that new Exception types had been added to the SPL, and when I first read it in Ralph’s article, I thought: “Big whup, extending the good ol’ Exception class is good enough for me.”

But I kept reading and now I’m really excited. See, it’s not just that there are new standard exception types, but there’s now a consensus way to incorporate exceptions into your library code. Zend and Pear seem to be agreeing, and while normally I’m not a fan of either’s code standards, this one I like.

In fact, I’m going to steal Zend’s standard nearly word for word:

• There WILL NOT be a top level anApp\Exception class
• Each package WILL define a marker Exception interface; subpackages may optionally define a similar marker interface extending that interface.
• Each package WILL define a generic <package>Exception class (eg. anApp\SmartObject\Exception), extending \Exception and implementing the component level Exception marker interface.
• Exceptions extending other SPL exception classes and implementing the marker Exception interface MAYbe created.
  • Exceptions deriving from SPL exception classes SHOULD be named after the SPL exception they extend, but MAY be named uniquely. In most cases, we would recommend using the original SPL exception name to prevent a proliferation of exceptions.
  • Exceptions not named after SPL exceptions WILL be named meaningfully: InvalidTemplateException, UnbalancedTagException, etc. Exception types can be re-used, but only if the name has a similar meaning in each context in which it is used.
• Because the previous requirement may lead to a proliferation of exception classes, exception classes MAY be grouped into an “Exception” subcomponent. The rule of thumb will be that if the number of exception classes exceeds 1/2 the number of regular classes and interfaces, they should be segregated.

This is exciting because it gives you tons of options for throwing and catching exceptions, and for providing context for your errors in a way other programmers can easily understand.

Now I just need to nail down the package/subpackage/class naming conventions. Woot!

[codesyntax lang="php"]

<?php
include_once(realpath(dirname(__FILE__).'/lib/smartObjects/lib.inc'));

\SmartObject\Connect(array(
                         'driver' => 'mysql',
                         'host' => '127.0.0.1',
                         'database' => 'testdb',
                         'user' => 'dbuser',
                         // not my real db user
                         'password' => 'dbpass'
                         // not my real db password
                     ));

\SmartObject\Register('User'); //Register "User" and get "Users" factory for free!

  $users = new Users();

  $users->sn('Johnson')
    ->or()
    ->sn('Clark')
    ->orderBy('sn DESC'); // No query is performed until we try to use the Users object to get at query data.

foreach ($users as $user) {
   echo "Setting access to 0 for: ".$user->gn." ".$user->sn."\n";
   $user->access = 0;
   $user->update();
}

echo "Setting access back to 1 for all users in our query.\n";
$users->beginTransaction();
$users->each()->access = 1;
$users->each()->update();
$users->endTransaction();

print "<ul>\n";
$users->each(
	  function($user) {
	     print "<li>".$user->fullName."</li>";
	  }
	);
print "</ul>\n";
?>

[/codesyntax]

Testing? What’s that? Sounds like it’d be a good idea. Someone should get on that.

This week’s problem came down to scope: there’s currently no way to call a closure and give it $this scope. My thinking was something along the lines of:

[codesyntax lang="php" tab_width="2"]

class foo {

	public $closures = array(
		'bar' => function($args) {
		echo "Class: ".get_class($this)."\n";
		echo "Method Bar called with:\n";
		var_dump($args);
		}
	);

	public function __call($methodName, $args) {
		if (in_array($methodName, $this->closures)) {
		  $this->closures[$methodName]($args); //or
		  // call_user_func_array(array($this, "closures['$methodName']"), $args);
		}
	}
}

[/codesyntax]

Crazy talk, I know. But this would let me do lisp-style advice and such. But no love.

So I have to come up with a hacky solution. I’m leaning now towards having advisable functions follow the convention of being private and starting with an underscore, but being called without:

[codesyntax lang="php" tab_width="2"]

class foo extends anObject {
	private function __bar() {
		echo "Called __bar\n";
	}
}

$foo = new foo();
$foo->bar();

[/codesyntax]

Then you can do something like:

[codesyntax lang="php"]

foo::adviseBefore('bar', function() {
	echo "Bar about to be called!\n";
});$foo = new foo();
$foo->bar(); // Echoes "Bar about to be called!\nCalled __bar\n

[/codesyntax]

Smashing Magazine has a good article today about interesting navigation designs. They showcase several sites and offer pretty good criticism, highlighting the pros and cons of the various sites’ unique navigation. My favorites were:

• Made in Haus — the dual sliding effects, even if I had trouble finding the navigation arrow
• Komrade — once I saw that the first link was below the fold, meaning that my screen was smaller than they had designed for
• Pline — for their minimalistic yet sexah vertical nav
• Retinart — because I’m a sucker for the nummy nummy typography

I really wanted to like both Flywheel Design and Made By Water but they made me have to think, and I hate doing that when I shouldn’t have to.

It’s been a while since I’ve kept a blog, so please bear with me.

My name is Bryan Johnson. I’ve been writing code professionally for about fifteen years now, and have been partner in a software development company for more than five. But I have no formal training, having studied Elizabethan-era English Literature in college. This background, along with a fair amount of skepticism when it comes to “the right way” of doing things, gives me a somewhat different view when it comes to writing code. That perspective is what I’ll be sharing here.

I expect I’ll also blather on a bit about my pet projects, and pretty much anything else that comes to mind.

I hope you stick around.