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):
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 ...
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.
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?
Debian and Ubuntu make use of the !includedir directive at the end of the packaged my.cnf to allow for extending and overriding their default configuration without having to modify the distribution config file.
This is especially nice in combination with configuration tools like puppet as it is usually much easier to add a file to the system than to modify an existing file.
I ran into a small gotcha with this though: the default my.cnf binds mysqld to the localhost TCP interface so that it listens IP 127.0.0.1 only. To make the mysql server reachable from other hosts the bind=127.0.0.1 setting needs to be overwritten.
How to change the binding to a different IP should be obvious, but how to disable an existing binding completely if you want your mysqld to listen on all available interfaces?
The most obvious would be to simply say
, this does not have any effect though. What needs to be done instead is
to make mysqld listen on all interfaces again.
This is obviously a solution for IPv4 only, for allowing incoming connections from all v4 and v6 interfaces allowing bind= without any argument to reset any existing bindings would probably be more clever?