What’s up with Getters and Setters?

27 Sep What's up with Getters and Setters?

I’ve been following Vic Cherubini‘s series on Zend Developer Zone about his ORM “DataModeler,” mostly to get some insight in to another programmer’s ORM design decisions, as well as to see if he had any nifty ideas I could appropriate for SmartObjects. Continue reading

Exceptions and the handling thereof…

16 Sep

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!

Smart Objects sneak preview

15 Sep

Here’s a bit of a sneak preview. I’ll let the code speak for itself:

[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]

One Step Forward…

14 Sep

Not quite two steps back. I’ve been plugging away at Smart Objects, as a way to get a feel for the rest of anApp5, especially the base anObject, the object that carries the functionality common to all anApp objects. See, I’m balls at TDD. In a perfect world, I’d spec out anObject and Smart Objects, write tests for them, then write the code (or somesuch methodology). Unfortunately I’m awful at that kind of coding. Undisciplined is one word. So I write some on anObject, then some on Smart Objects, then tweak out anObject when I hit a wall with Smart Objects… Back and forth, back and forth.

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]

From Smashing: Showcase of Interesting Navigation Designs

7 Sep

Showcase of Interesting Navigation Designs

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.

Back in the saddle, again…

2 Sep

Welcome to Debuggery!

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.

Follow

Get every new post delivered to your Inbox.