On phpseclib's PHP4 compatibility
Within the PHP community, there are those who are so evangelical about PHP5 that they believe they ought to go out of their way to intentionally break their code on PHP4. "We need to increase PHP5's adoption rate by making it so code will *only* run on PHP5!" they say.
I'm all for writing PHP5-only code but only if doing so actually gains me something. For phpseclib, nothing is gained by intentionally breaking phpseclib on PHP4.
- PHP5 introduces private as a keyword. If you try to call a private function, you'll get a fatal error. Of course, chances are, if you try to call an undocumented function that is *intended* to be private in PHP4, you'll get an error, all the same. The only difference between the two is that one of these errors is probably going to be easier to understand than the other. You will, however, in both cases, get errors, regardless, so breaking PHP4 support so a "pretty" error can be displayed seems unnecessary.
also, see Visibility in PHP. - PHP5 also introduces the notion of interfaces. Through their use, any Crypt_* object implementing the class Crypt base object (for example) would error out if it didn't implement all the functions defined in the interface. The way to avoid the error is to implement all the necessary functions and that can be done with or without an interface.
Ultimatley, interfaces are there primarily for the benefit of developers. "I think I've finished this class - let me run it! Oops - forgot to implement the foo() function - let me do that quickly and then I'll test it!". ie. a developers own test cases might not test for the foo() function but an interface will. It's like a run time unit test and... well, I just don't think that's a useful enough feature to break PHP4 compatability for. - PHP5 introduces autoloading, as well. Here's an example:
- Code: Select all
function test()
{
echo 'hello, world!';
}
spl_autoload_register('test');
$a = new a();
When that code is ran, you get a "hello, world!" message and then a fatal error. Now consider this code:- Code: Select all
class a {}
function test()
{
echo 'hello, world!';
}
spl_autoload_register('test');
$a = new a();
No "hello, world!" and no error. spl_autoload_register() makes it so that when a non-existant class would be initiated a predefined function is called before displaying an error. The idea is to make it so you don't have to include a bazillion different files. phpseclib includes lots of files but I don't believe those includes to be so unsightly as to justify their removal and replacement with autoloading. - PHP5 introduces class constants. instead of having NET_SSH2_MASK_CONSTRUCTOR you'd have Net_SSH2::MASK_CONSTRUCTOR. i don't really see what's gained by that, however.
also, it doesn't really work well with those constants that are defined by Net_SSH2::_define_array() - PHP5 introduces the ability to throw exceptions. It's superior to user_error() since exceptions can be caught but it's not so superior that it's worth breaking PHP4 compatibility over.
- PHP5 introduces reflection. How this is of any benefit to phpseclib, however, is beyond me.
- PHP5 introduces prepared SQL statement support and provides DOM support for XML parsing. that's all nice and well, but phpseclib doesn't use SQL or XML.