PHPreboot braindump

Looks as if we have the next member in the "I want to become Caliph instead of the Caliph" club: PHPreboot

This is just a braindump of thoughts on the various bullet points and examples on the projects home page (but i don't think it's worth any more time to analyze it and comment on it either):

• less $, less ';' like in javascript

Not sure whether this is really an improvement, while $ and ; are not really necessary from a parsers (or lazy typers) point of view they do carry some context information ... so this is breaking the "The burden shall be on the writer, not the readers" principle IMHO

• secure by default: no eval, no magic quotes/string interpolation

Yes, that's all that needs to be disabled to guarantee secure code ... NOT

Magic quotes were a bad idea, but for slightly different reasons. eval() by itself is not a bad idea either if used properly, same as with backticks, system(), popen(), ...

And just by disabling magic quotes and eval() you do not make code secure by default, XSS and SQL injections can still happen without these, and i'd bet that most malicious code injections in vulnerable PHP apps were not using eval() but include/require as attack vector to make PHP execute their own code ... want to forbid these, too?

• full unicode support

That's a good thing, we may just have different ideas of "full" ...

• no from/to string auto-conversion

I do like the "to" part of it ... not really sure about the "from" part ...

• a SQL compatible syntax

Which SQL dialect? And looking at the code: how would i handle queries against multiple database connections?

• Perl 5 regex literal

I personally prefer to write preg_match() literally ... but that may be just me and my PERL allergy ...

• URI/file literal

I don't see that much gain in that one over explicit fopen(), ... calls either

• fast as Java thanks to a runtime profiler/optimizer and JSR 292 API

There's room for improvement in PHP optimizers and op code caches for sure ...

In my personal use cases a JVM based PHP would actually be a loss though. Most stuff i'm using PHP for these days is medium complex command line stuff (like my code generators), and for most of this my PHP scripts are already done with their job in a time that would not even be sufficient for a JVM to initialize and execute the very first byte code op of my user code

There's also the more general issue that when going the way of the JVM you either go bytecode all the way and have to say goodbye to all the PHP extensions that are actually just thin wrappers around native C libraries, re-implement those libraries functionality in a language supported by the JVM or go the way of JNI ...

• provide an embedded database derby and a standalone web server grizzly by default

... instead of SQLite and ?forgot-the-name-of-the-upcoming-integrated-webserver-thingy? ...?

• native XML syntax

Sorry, can't see how that's "native XML syntax", PHP and its use of XML processing instruction syntax is as native as you can get, hiding executable code in DATA not so much

• Language as close as possible to PHP

Sorry but even that simple example does not really look like PHP to me as all. Maybe part of that is due to the use of "elseif" instead of "else if". I haven't seen any PHP code using "elseif" in years, i even had to double check that it works in this context and not just in the IF: ... ELSEIF: ... ENDIF; form.

• native XQuery

Again i'm not sure whether i want to have that on the Syntax level ...

• [...]

So to summarize:

• the language does hardly look like PHP anymore (actually looks more like a PERL/Python chimera to me personally)
• the language will not be backwards compatible to PHP syntax wise (afaict)
• the language will not have many of the functionality that PHP gets from native C libraries

=> so why should it have the letters PHP in its name at all?