Unlike other SPL interfaces, I'm not finding that this pair of built-in interfaces has any intrinsic value other than to provide a template.  It would be nice if Observer can automatically trigger its `update()` method any time Subject properties are modified in any way, but this isn't the case.  You have to set it up manually.

So to start, you want to separate `contrlr` into separate SplSubject and SplObserver classes.  Otherwise, for all intents and purposes, it's only notifying itself.  `model` can actually be the one that implements SplObserver in your case.  But really, which class implements which interface would be up to you.  Here's just an example of a basic usage...


	class obs implements SplObserver {

		function update(SplSubject $sub) {
			echo "notified: " . $sub->status . "\n";
			}
			
		}
		
	class sub implements SplSubject {
		private $status;
		private $obs;

		function __construct(SplObserver $obs) {$this->attach($obs);}
			
		function __destruct() {$this->detach($this->obs);}
		
		function __get($prop) {return $this->$prop;}
					
		function __set($prop, $val) {
			$this->$prop = $val;
			$this->notify();
			}

		function notify() {$this->obs->update($this);}
			
		function attach(SplObserver $obs) {
			$this->obs = $obs;
			$this->__set("status", "attaching\n");
			}
			
		function detach(SplObserver $obs) {
			$this->__set("status", "detaching\n");
			$this->obs = null;
			}
			
		}
		
	$obs = new obs();
	$sub = new sub($obs);
	$sub->status = "testing";

Edit: you can also make a new class "view" which extends "sub".  "view" can have a method to grab stored messages or properties from "obs".  That should complete the diagram.