On Choosing Linux

August 29th, 2004 • 1 comment Linux

Brian Jones on Linux.com writes:

Many admins who got the OK to get Linux in the door a few months ago have had to face a lot of people with ties on and arms folded standing outside their cubicle after Red Hat made its end-of-life announcement: Red Hat would no longer release updates for Red Hat Linux 9 and would no longer distribute free ISO images of its releases. The alternative, Red Hat Enterprise, costs money, which invalidated one argument that was useful in getting Linux in the door in the first place.

Yes, many admins did get Linux in the door, and the fact that Red Hat decided to stop supporting their free (as in beer) distribution doesn’t mean that Linux is coming to an end, in fact, it’ll probably move in the right direction for once.

Read more »

ActiveState Komodo 3.0 Pro

August 26th, 2004 • 10 comments General

DISCLAIMER

The author is not affiliated or sponsered by ActiveState. He only likes to talk about products he likes, so this review is totally objective, and the author’s point of view might not represent ActiveState’s.

Built with XUL’s flexibility, powered by Scintilla, and armed with ActiveState’s brilliant minds, Komodo became my favorite IDE ever!

Before 3.0, Komodo used to be too slow to an extent where I’d rather run notepad instead. With the newest release, Komodo is able to cope with dynamic syntax checking, class analysis, and customizable interface without loosing its speed; in fact, Komodo now runs much faster than ever before. It even runs faster than some native IDEs whether on Windows or on Linux.

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.