develooper Front page | perl.advocacy | Postings from August 2001

My list of PHP's shortcomings

Thread Next
From:
Nathan Torkington
Date:
August 21, 2001 22:04
Subject:
My list of PHP's shortcomings
Message ID:
15235.15663.734000.977202@gargle.gargle.HOWL
Here are my reasons why the idea of using PHP on big projects scares
me:

1) No namespaces.  You pick a prefix for your function names (e.g.,
"mysql_") and that's all you've got.  There's no relationship between
the name of an an included module and the prefix.

2) All functions are global.  This is related to (1).  No importing,
no module interfaces except documentation.  Nothing like Perl's
@EXPORT_OK to indicate the acceptable functions to use.

3) No real references.  A variable never holds the address of another
variable.  You can hold the name or create a new variable with the
same storage.  Complex data structures are done with state of the art
perl4 symbolic references and eval().

4) Did I mention no real data structures?!

5) There's no equivalent to sub {FOO} where FOO is compiled at
compile-time.  create_function() takes a string that's compiled at
run-time.  The reliance on runtime eval() makes for fragile dangerous
code.  They aren't even real anonymous functions--they have names,
it's like gensym().

I've tried to steer clear of "this confused me" type of criticisms and
stuck to what I think are widely acknowledged as obstacles to large
program development.

I'm not saying Perl is perfect (I lust for function signatures that
make   my($a,$b,$c,$d)=@_   redundant, for example, and Perl's power
comes at with a learning curve price) but you asked for reasons that
PHP might be unsuitable.

Cheers;

Nat


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About