Monday, August 4, 2008

google vs. democracy

maybe my last blogpost here :) google tries to overthrow democracy by banning MPL from google code. is the open source license jungle proliferation or variety?

Wednesday, July 16, 2008

static classes

There is a proposal for static classes in the official php wiki. Interesting? Yes, in some way, but in no way that i like. If you are one of the code monkeys that discovered object oriented programming in some depth, you probably dislike static like me. If not, my further explanation may give you a clue.

Static is evil. Not enough explanation? Ok.

Static is evil because it exists. Still not enough?

Static is evil because it has been invented. *grmbl* I'll try the long route...

Let us start with the abbreviation OOP. The words Object Oriented Programming gives me the feeling that it has to do with objects. And objects are instantiated from classes. But the evil static declared stuff don't do anything to objects, it just belongs to the class and not the instance. (Ok, in PHP it's not exactly like that but it's the way it should be.)

So does all the static stuff has anything to do with OOP? Uhm, no. Can we make it more OOP? "We could make interfaces for static classes available! It's totally OOP!" Yes it's OOP, but it won't help. Why create an interface based static class if you can't replace it with another implementation? That's the idea of interfaces! "We can replace a class by an namespace import? Or we can call_user_func() all the time?" Oh, please! We have all this already with objects! Interfaces are useless for static classes. We can mimic abstract and singleton behaviour - for it's rare uses - in userland.

Static only exists to make old-school procedural programmers feel nice. You don't really need it in OOP and you don't need a even more complex static magic on earth. Actually all the static stuff could be thrown away with namespaces and closures for regular functions. Can you imagine?

Don't get me wrong, i use static methods sometimes and i love functions. But static classes would be a change in the wrong place.

Friday, June 27, 2008

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 ) ) ) ;

Friday, June 6, 2008

mysql stored procedures point of view

Stored procedures in mysql totally suck! The syntax is far behind any usability, debugging is impossible, error messages are meaningless. Using result sets? A joke! And if you created a procedure after hours it's likely that it don't work.

I think a stored procedure in mysql is thinking this:

Darkness imprisoning me
All that I see
Absolute horror
I cannot live
I cannot die
Trapped in myself
Body my holding cell

Metallica, One

Wednesday, March 12, 2008

Early Aprils Fool?

Real gurus write simple code. Thanks universe!

Friday, March 7, 2008

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.

Friday, February 29, 2008

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).