After a very long time in development, changes and bugfixes PHP version 5.3.0 has been released as stable.
( http://news.php.net/php.internals/44538 )

The changelog is pretty big but some stuff stand out since they have been discussed extensively over the last year or so.

My favorite parts of this release (after namespaces and anonymous functions of course) seem to be the following.

• Added “?:” operator. (Marcus)
• Added support for __callStatic() magic method. (Sara)
• Added __DIR__ constant. (Lars Strojny)
• Changed __call() to be invoked on private/protected method access, similar to properties and __get(). (Andrei)
• Added NOWDOC syntax. (Gwynne Raskind, Stas, Dmitry)
• Added JSON_FORCE_OBJECT flag to json_encode(). (Scott, Richard Quadling)
• Added mail logging functionality that allows logging of mail sent via mail() function. (Ilia)
• Added gethostname() to return the current system host name. (Ilia)

Now that namespaces are a native part of PHP let’s see how will people manage to abuse them. ^_^

Minutes after the official Google announcement (and a comic strip) that they are about to release a beta (windows only) version of their new webkit based browser the internet flooded with so many posts about Chrome and the future of the internet.

Webkit, V8 Javascript Virtual Machine and “One Proccess per tab” are enough reasons for most users to dump everything else.

Other than just wanting to mark this day myself I will not say anything more other than… Hell yeah.

One thing I love about javascript is the anonymous functions it provides.
It allows you to create and use one-time functions that you don’t have to ever see again, use or think how to name in order not to mess with your pretty coding standards.

I found a post by Daniel Cousineau on php5.3’s closures that lead me to the closures rfc.

Anonymous (or lambda) functions are extremely useful for callbacks or an quick and dirty way to create extensions or overrides for your code.
The examples are stolen from the closures rcf.

$lambda = function () { echo "Hello World!"; };

That was it. Now you can call it anyway you want.

$lambda ();
call_user_func ($lambda);
call_user_func_array ($lambda, array());

The patch is actually created to allow closures support, something also very common in javascript.
Closures are used to change the function’s scope so it can access specific variables that normally the function would not have access to.

The examples in the rcf are pretty simple but get the point across.
The following example is something I didn’t thing would work, but I still ain’t sure how the lambda functions’ scope works.

class something
{
	public $hello = 'Hello world!';

	public function world()
	{
		$x = function () { return $this->hello; };
		return $x();
	}
}

$s = new something();
echo $s->world();

This actually shows “Hello world!”…
The weird part is that the function acts like it is a method of the something class and can see $this.
If you were to make a normal function it wouldn’t have access to $this.
I’ve submitted a bug report about this but I’m pretty sure it’s a feature since you can’t use $this in a closure.

Update: The reply to the bug report was:

This is the intended behavior. Use “static function” if you don’t need $this.

So there goes… ;)

Owh — my — gawd!

I’ve just noticed a very pretty patch by Sara Golemon (I think?) that allows static __call magic function.
If that sounds weird or plain useless then… you are just about right…

The new magic function is currently (php5.3 and php6 CVS HEAD) called __callStatic and you should be aware that it has some issues.

So, what good is this…
It would be a good way to create overloadable static methods that would allow the user to call the same class method with different number of arguments or different argument types and get different results.
Same way overloading works in other programming languages.

very simple example.
users::get(1); //Returns user with id 1
users::get(”email”, “b.gates@microsoft.com”); //Returns user with email address b.gates@…

There should be other cute things that could be done with this, especially if it was backported earlier in php5.x where namespaces didn’t exist.
But since the first version to implement this will probably be 5.3 that will also include namespaces the glory of the static __call method is faded.

To be honest I wasn’t looking for this when I bumped onto it.
I was looking for a way to implement a static __get method.
Since the lovely core developers of php actively deny to let the users define their own custom superglobals (like $_SESSION, $_POST, etc) I’ve been trying to find a way to call some objects from any scope without having to register them as global first or call them through a registry or singleton pattern.

I frequently end up having several global objects that everything in my Php application needs and having to remember to global everything is a pain in my ass.
A registry or a singleton pattern would seem the way to go here but still I don’t quite like either.
object::getInstance()->doSomething(); //Singleton pattern inside the class
singleton::getInstance(”object”)->doSomething(); //Generic registry pattern

Now imagine that you could define $object as a superglobal…
$object::doSomething();

The problem with this is that in order to do this you need to have the runkit extension or custom patch your php but then you have to watch your code portability go down the drain.

So my last hope was using a static __get method that would return the global object using the requested variable. (did this make any sense?)

< ?php
class superglobals
{
    public static function __get($var)
    {
        global ${$var};
        return ${$var};
    }
}
?>

This is currently wrong for so, sooo many reasons, but wouldn’t it be pretty if it actually worked?
There are no static __get or __set methods not even in the php6 schedule and this saddens me but I’ve got faith in the core php team that they’ll make up for it with namespaces, threadding and native utf support. — And maybe custom superglobals? Pretty please?

Being a geek since I can remember, all the conversations around best, or more frequently worst coding practices reach the same conclusion.
“Monkeys should never be allowed to code.”

Most developers, (especially web ones) have a bit weird habits when working under pressure and face the oldest dilema of them all; “nice code” vs “fast code”.
And since “fast nice code” doesn’t really exist in this universe, most of these creatures decide to follow the fast track, making other people’s lives unbearable.

Coding patterns, standards and common sense are all tossed aside, torn apart, stepped over and betrayed – all in the name of deadlines and ready made libraries that no one really knows how to use or has bothered rtfm-ing.

So why the undead? Cause every time one monkey dies (or for some weird phenomenon starts behaving like a gentleman), ten more monkeys appear. It’s like zombies I tell you.

Having stepped over all these things a couple of times myself, I figured it was about time I tried to convert a tiny part of this undead horde™ to something more humane.
Php, Javascript, XHTML and Css pitfalls will be the main dishes of the days to come. (And hopefully ways to help you and me get out of them.)

The start of this blog was a result of the very small number of blog entries and general info around some very useful and common patterns especially in php that could actually save your life. For example localization and hierarchical data structures (like modified preorder traversal trees, aka mptt) are scaring the hell out of people with no apparent reason.
I promice nothing even remotely close to the road to enlightenment, rather some basic guidelines and tips how not to miss the road sign (big yellow flashing arrow maybe?).

So let’s go hunt some monkeys :)

ps. I’m a blogging newbie so please bear with me, (and kindly report) my spelling errors and sentences that don’t actually make sense. :)