Stubblog - No Stubbles

Just for the record

nospam@example.com (Frank Kleine) — Mon, 30 Mar 2009 16:53:32 +0200

Once again, I have to mess around with SOAP, certainly not the last time. For the record: SOAP is for sure one of the first places on the top ten list of the most stupid inventions in software history.

We are hiring!

nospam@example.com (Stephan Schmidt) — Mon, 18 Jun 2007 21:39:13 +0200

Are you looking for a job? Are you living in Germany? Do you like Java?

If you answer all these questions with 'yes' and would like to work with the Stubbles' developers, than you should apply for a job in my team. We are looking for two Java Web Developers, that are also familiar with XML/XSLT and OOD/OOA. Knowledge of other languages like PHP or Javascript are helpful, if you are applying for this job, as you might end up developing with Stubbles. If you are interested, take a look at the (German) job description.

My wishlist for PHP 6, pt2: Namespaces

nospam@example.com (Stephan Schmidt) — Tue, 20 Feb 2007 20:50:52 +0100

I won't go into detail here, as this topic has been discussed a thousand times on internals. Although prefixing all of your classes works, it still is a PITA. In Stubbles, we are prefixing all our classes with stub, which is fine, as it is a kind of funny prefix, but there are some cases, where this really sucks.

In our implementation of annotations (stay tuned for a tutorial on annotations), every annotation is converted to an object. In our first implementation, the class name had to be the same as the annotation name, but this leads to annotation names that aren't that beautiful to read The XMLSerializer component allows you to use the annotation @XMLTag to specify how an object should be serialized to XML. But the classname XMLTag should not b used as everybody could imagine a future xml extension grabbing the class name. To overcome this drawback, the annotation parser will pre- and postfix the annotation names, so the annotation @XMLTag loads a class called stubXMLTagAnnotation. Namespace support would help us get rid of these little annoyances, as we could import the XMLTag class from the package net.stubbles.xml.annotations. So unless someone comes up for a good reason against namespaces, they will hopefully be part of PHP 6.

BTW: Please spare me the "PHP is not Java" comments, as I already know this.

My wishlist for PHP 6, pt1: The 'object' type hint

nospam@example.com (Stephan Schmidt) — Mon, 19 Feb 2007 19:45:42 +0100

I was very pleased, that PHP 5 introduced type hints, although they are not available for primitives like string, int, boolean, etc. Still, I'd like to see the object type hint introduced in any future version of PHP that allows me to specify, that a method or function only accepts an object, regardless of the type of the object:

class Processor {
    public static function processObject(object $obj) {
        echo get_class($obj) . "\n";
    }
}

Currently you always have to specify a class or interface name, but I can't see, why this is needed. In Java, this is no problem, as they have a common base class for all of their classes, which is not the case with PHP. So when trying to call this method with an object like this:

class Foo{}
Processor::processObject($foo);

you get the following error:

Catchable fatal error: Argument 1 passed to Processor::processObject() must be an instance of object, instance of Foo given, called in test.php on line 14 and defined in test.php on line 6

The reflection extension lets us do a lot of funky stuff without knowing anything about the passed object, so I can't see a reason why this feature should not be implemented. If this already is possible in PHP, please let me know. If not, I hope that Marcus Börger is reading this entry and will implement this for PHP 6 . And yes, I'm well aware, that this might create some problems if anybody has a class named Object, but please don't start another namespace flamewar (although namespace are one of my other wishes for PHP 6).

And while we are talking about it: What about a ressource type hint, that will only accept ressources, that can be processed by functions like fread() and fclose()?

Pavlov

nospam@example.com (Frank Kleine) — Sat, 17 Feb 2007 11:35:05 +0100

Yesterday Stephan announced the Stubblog, and because the blog is included in Planet PHP (which the Stubblog will not be due to their policy to not accept project-only feeds) it forced some reactions which reminds me a bit of Classical Conditioning. And I believe that none of those complaining really read what Stubbles is about.

Yes, PHP will never have something unifying like Rails. But are there really too much frameworks out there? I don't think so. Competition is a good thing. It is about choice, striving for new ideas and combining them in ways no one thought before. I believe that Ruby in the long run has a serious drawback in only having Rails. Because there is only Rails people who don't like it will not start using Ruby because they don't have the choice to use another framework.

But I admit, there is a problem with too much frameworks. Its about specification. PHP has no specifications. The lack of the PHP community to define such specifications will bring a lot more of new frameworks for us in the future that are not compatible. In Java no one complains about competition between frameworks. They have specifications, and frameworks stick to those making it easier to switch between them because they have the same API. Yeah, I know PHP is not Java. It should not be in the language. But it should learn from their way of defining specifications. As long as this does not happen the rants about YAF™ (Yet Another Framework) will not lead us anywhere.

Enough ranted. In a forthcoming blog entry we will write why we develop Stubbles and did not stick to another framework. Stay tuned.