An unorthodox implementation of Observer pattern

This is how py-notify describes itself. And it really is. Most observer implementations I've seen look almost like the good old Observer Pattern from GoF. Although it does the job, it could achieve more loose coupling with some changes. The unorthodox in py-notify is that the events (signals) are not typed. You don't need to pass constants like 'onSomeEvent' around or more worse event objects (but you can do both). Also unorthodox is that you don't need any interfaces for the observers since it's possible to register every method or function. This makes the implementation less verbose and type safe, but much more flexible and easier to implement.
Py-notify has much more to offer on top of the signals concept, but I'm currently only interested in the pure observer concept and partially ported it to php. code/examples

Here is an simple Observer example:

class Observer {
function notify($msg) {
echo "Subject says: $msg\n";
}
}

class Subject {
/**
* @var ekn_Signal
*/
protected $signal;

function __construct() {
$this->signal = new ekn_Signal();
}

function addObserver($observer, $method = 'notify') {
$this->signal->connect(array($observer, $method));
}

function saySomething() {
$this->signal->emit('something');
}

}

$subject = new Subject();
$subject->addObserver(new Observer());
$subject->saySomething();


gbook help, plz^^

i'm new to php but i'll make a gbook!!!

i have code!!

but i'm scripting for hourz now and i can't find errorz in my scriptz!!

help plz!!

herez my code^^


$_=reset(get_defined_functions());$i='><input';
$_[242]("<form$i name=$i type=submit>")&&$a?$_
[459](8,$a."\n",8):8;$_[242]($_[230]('<li>',$_[
457 ] ( 8 ) ) ) ;


Early Aprils Fool?

Real gurus write simple code. Thanks universe!

needful things - traits

Via lukas post i figured out that there is an traits proposal for php. Read more about traits.

If you get into it, you'll see traits could be a kick ass feature! This needs more attention, so share with your nerd-friends!

PHP and SimpleXML namespaces

Last days i did some web scraping with PHP and decided to use simplexml's xpath feature to get it done. But the xpath stuff caused massive headache. The problem: I wasn't able to execute any xpath expression on the simplexml document. Not any! Because i had no idea what the problem is, i googled a little bit and found some hints. The xpath engine need to know about namespaces (registerXPathNamespace to the help) and isn't able to use default namespace.
So what went wrong? As a orderly guy i've used tidy to make the maybe not well formed xhtml document parseable for simplexml. Of course i've exported xhtml with tidy and pedantic tidy added namespaces in this case.
Obviously the solution was simply to use tidy with output-html instead of output-xhtml option.

I probably never encountered this problem if i've used this little workaround with domxml::loadHTML:

$dom = DOMDocument::loadHTML($html);
$page = simplexml_import_dom($dom);

I guess the dom function will fix most common issues with broken html.

eval is still evil

Here is an interesting code snippet from the simplicity php framework:

//...
static public function check($path=false) {
if (!self::loadFiles($path)) return false;

$arr = "";
$apath = explode('.',$path);
foreach ($apath as $pt) {
$arr .= "['{$pt}']";
}

$var = 'self::$_settings'.$arr;
$eval = "return isset({$var}) ? true : false;";
return eval($eval);
}
//...


What happens? This code traverses through an multidimensional array with N dimensions.
Yes, recursion is sometimes tedious. But if i can avoid an eval call, i avoid it! The solution without eval is not longer and not much harder to understand and written in nearly the same time:

$data['foo']['baz']['wtf'] = 'whupass';
$path = 'foo.baz.wtf';

$p = explode('.', $path);
$value = $data;
while ($k = array_shift($p)) {
$value = $value[$k];
}

echo "$value\n";


Cute, isn't it?

deconstructing xyster

I've stumpled across a new framework called xyster and it's not surprising that behind the fancy web 2.0 website is lurking something evil.
Xyster is an extension to Zend Framework and extends ACL, MVC with some features and uses the Database Layer for an ORM package. So what is the evil in xyster? Evil is the Xyster_Collection package. Everyone who knows Java's collection mess. Everyone who envied languages with object oriented array's. Will have some (good or bad) emotion now. But this is not the point. The points are interoperability and simplicity. It isn't easy nor fun to convert from/to collection Foo, again and again. Indeed, in Java this is common, but Java sucks exactly for this reason (and some others)! PHP does better, just hand over some native array's that work everywhere. And if you really need a fancy collection-like-something, create an highly specialized version and integrate it in the specific domain.

There is one small chance to create a collection framework for PHP that is interoperable. Write an RFC. Write an native extension. Start an petition. Pray. An don't forget to become a landowner, in case rasmus comes around and kills you with a roundhouse kick.

This fact would be a great disadvantage, if i had a need for xyster (or any other framework with the same flaws).