Emacs!!!
XEmacs!!!
Emacs!!!
XEmacs!!!
Now seriosly kids.
My opinion is that none of the modifications that have been discussed
actually change the language into something better. Everything that you can
do with the proposed modification, you can do without. Sure multiple
inheritance makes this easier, but opens up cans of worms only solved in
hundreds of development iterations. Sure typing (even optionally) keeps you
from shooting yourself in the foot, or at least from hurting yourself too
bad while doing it, but it also makes it just a little more difficult to
program. Operator overloading makes it so that you don't have to type so
much, but adds no functionality to the language (It bugged me too until I
learned Java, and what is referred to as operator hell). Case Sensitivity
just makes it so that if you can't remember if it's myFunction or MyFunction
or myfunction or MYFunction or myFUNCTION (you get the picture) you have to
go and look it up before your script will run.
I propose that all discussion of adding to or changing the language itself
be suspended until such time as it can be demonstrated that PHP can be
maintained in and of itself in its current state, and this by use of the
following milestones:
* A complete regression test suite that is maintained concurrently with the
development effort. Each bug that is fixed receives a test case to be
checked with make test). A lot of extensions don't even have test suites.
And last time I ran make test, the results were so useless and
non-representative that I no longer try to run it. (Granted that was a
couple of months ago.)
* Nightly snapshot builds on the big three: Linux, Windows, and Solaris.
I/My company can donate cycles to this task on some pretty nice machines if
needed.
* Complete core compatibility on all *NIX platforms as well as Windows. If
a function cannot be implemented on any given platform, it should be
deprecated/removed from the core. Register_Shutdown_function comes to mind.
* Average new daily valid bug reports should be less than 10. Average
daily open bug reports should be no more than 100. I've got ideas on how to
help make this happen, and will release them to any who asks.
* Extensions that do not compile and function on every platform should be
removed to some non-core location. If it's not portable, then it's not PHP.
* Complete documentation on every extension and function and structure and
operator and nuance and etc of the PHP core.
If and only if all of the above conditions are met can we think about
extending/tweaking the language. If we do, any more than has already been
done, before we have that solid base, PHP is going to be so top heavy, and
so bottom weak that it will collapse.
Joseph
P.S. RANT Abstract=Why my company, and as a result, I won't be using PHP
anymore, and why this discussion won't change that outcome.My work with
php has come about because we decided that php would be the best platform in
which to create a web application. We had experience with mod_perl, CGI, as
well as Java, and by far the easiest to use and the quickest to develop in
is PHP. The entire application was written procedurally. Only at the very
end did I create a class, and that because I didn't feel like passing 6 or 7
parameters when I made a function call and I was being lazy. I never was
upset because php didn't have this language feature or that OO nicety.
What did get me was the non-portability of the supposedly portable
Scripting Language, but there are open bugs on all of those issues.
Nobody's even tried to touch those bugs, but they're open. Now, because of
the gotchas we had with the first app, the next web application will be done
in C/C++ because it turns out that PHP is not as portable as we were led to
believe. This feature or that feature or the other may or may not be
available on a given platform.
We all have more important things to do: I'd really like the
Register_Shutdown_function bug that's been around since the release of 4.1
to be fixed. Then while you're at it, get it working on Windows. That
takes precedence over ANY language extensions in my mind, as do all of the
open bugs in the bugs database.
On a different vein: have you ever tried selling a PHP application to a
customer? How about a customer that only has Windows/IIS in house and
doesn't feel comfortable about bringing in a *NIX/Apache server in to deploy
your product? They care not about whether it is case sensitive, or how
Object Oriented it is. They want it to run, run well, and run without
crashing. As a general rule, PHP/IIS is experimental at best, but nobody
seems to want or to be able to work on it. So we lose sales... I've tried,
but failed because I can't understand the Zend engine. What do those lost
sales translate to? You guessed it, our next application will not be
developed in PHP, and our current app probably will be rewritten in C. And
I won't be able to contribute anymore. Such is
