That’s What They Think

October 23rd, 2004 • 1 comment PHP

Just downloaded J2SE 5.0, and turns out here’s the reason why they think PHP isn’t enterprise-ready:

PHP, Enterprised!

October 18th, 2004 • 3 comments PHP

I’m sure we’re all bored with all these discussions about PHP being ready (or not) for enterprise computing; I know I am.

I think we’re all missing the point here, like Marco Tabini said, it doesn’t really matter if PHP is enterprise-ready or not, an enterprise-level company doesn’t care if you’re using PHP or mashed potatoes to get the job done, if the budget allows it then by all means use whatever you want. Nobody’s interested in hearing three-letter buzzword-like acronyms, nobody cares what you’re doing underneath, just as long as you make sure a patient’s heart doesn’t stop, or tons of money aren’t transferred by mistake to Nuke-The-World organization.

Yes, PHP is enterprise-ready, if you want it to be. It can do whatever you want it to do, from messaging, to RPC, to persistence, but are you willing to invest?! Are you willing to develop modules, extensions, APIs and standards? PHP is a monolithic monster, it’s not easily extended, but it still has lots of advantages, lots of potential, but are you willing to invest?!

Developing any project with PHP implies many costs, this includes the learning curve, integration, interoperability, deployment and obviously speed of execution. Each comes with a certain cost, each impacts a project in a different way, and each contributes to moving PHP further into the enterprise market.

Read more »

Can PHP be owned by Sun?

August 7th, 2004 • PHP

Just spotted an interesting article speculating on how the new changes in PHP5 can be a sign that it might be owned by Sun in the near future.

Well, the new changes in PHP5 are tremendous, and they do bring PHP5 much closer to Java in terms of OO design, except PHP5 isn’t Java, and probably it’ll never be!

What makes PHP compelling to new comers isn’t how it handles OO, it isn’t PEAR, and it certainly isn’t that it can be mixed with HTML code, barely anyone uses that; it’s that it’s easy to pick up compared to other languages, like Perl for instance. If PHP loses this, it won’t be as appealing as it is now, so it’s not in anyone’s benefit for PHP to become, God forbid, Java; we already have one.

PHP is an open-source project, probably not in a way that FSF would define it, but still, you can have the source code, play with it, even compile it and sell it, it’s nobody’s business. This is to PHP’s advantage, and a lot of develops feel somehow secure knowing that even if a company like Sun acquires Zend, they can still fork the whole project and go in separate ways. That doesn’t mean that if Sun does acquire Zend is a necessarily bad thing, it might for PHP’s own good. But the fact that Sun is considered a not-so-open-source by many pro-open source develops, can be disturbing.

I personally agree more with Rasmus’s view on where should PHP go from here, namely to Parrot. It runs better, it’s interoperability with other languages running on Parrot reduces code rewrite, and can easily compete in Java’s market, and probably .NET’s too. I don’t think there’s any there’s any real reason for developers to worry about PHP’s future, we’ll still be able to write scripts and applications in PHP without having to put any commercial threat into much consideration.

Some PHP5 Gotchas

August 4th, 2004 • 1 comment PHP

Fiddling around with PHP5, I’ve stumbled upon some interesting gotchas, some of them might be too obvious to mention, but sometimes the obvious is only too obvious that we don’t even notice.

Static variables and functions

PHP5 supports both static variables and functions (i.e. do not need an instance to be called), but for some reason, PHP5 doesn’t allow overriding static variables in a subclass:


<?php
class Base
{
    static $var = 4;
}

class Sub extends Base
{
    static $var = 5;
}
?>


Fatal error: Cannot redeclare property static public Base::$var in class Sub in /path/to/script.php on line 13

Interestingly enough, static functions can can be overridden, so the following code would run without any errors:


<?php
class Base
{
    static function func()
    {
         echo "Called from Base\n" ;
    }
}

class Sub extends Base
{
    static function func()
    {
         echo "Called from Sub\n" ;
    }
}

Base::func(); // outputs "Called from Base"
Sub::func(); // outputs "Called from Sub"
?>


Variable class names

Methods cannot be called statically if the class name is stored in a variable, I’m not very sure why, but I’d guess it was too much of a headache to implement. For example:


<?php
class Base
{
    static function func()
    {
         echo "Called from Base\n" ;
    }
}

$class = 'Base';
$class::func(); // WRONG!
?>


Would generate:

Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /path/to/script.php on line 52

The only way to do it is to use call_user_func() or call_user_func_array(). Using the above Base class, this is how func() should be called:


<?php
    call_user_func(array($class, 'func'));
?>


Same applies to calling class constants, there’s no way to get a class constant with a variable class name without using constant().


<?php
class Base
{
    const BASE_CONST = 'CONST_VALUE';
}

$class = 'Base' ;
echo $class::BASE_CONST; // WRONG!
echo constant("$class::BASE_CONST"); // RIGHT
?>


I know that these are some picky stuff, but I still would like PHP to support these, because at the very least, the code would look better.

PHP5 Released!

July 15th, 2004 • 1 comment PHP

Congratulations, finally PHP5 is released, grab yourself a fresh copy now.

Now all is left is to actually make use of it, for some weird reason I feel that PHP4 will stick around for a while. Still, expect pains and sleepless upgrade nights, you never know what your boss might say.