PHP Hacking aka trying to push PHP internals forwards

I've read a lot of the PHP internals source code (I'm an author of phc), and this post leaves me a tiny bit optimistic, and a tiny bit disappointed.<p>I completely agree of the need to fork to make PHP a better language. The PHP internals community is the most awful OSS community I've ever been involved in, and getting shit done there just isn't going to work. So this is a good first step.<p>I also like the things he has taken away. PHP suffers from too many unnecessary options. I know that "unnecessary" is often subjective and in the eye of the beholder, but the OP seems to have a good eye for this. The things he removed are a blight on the codebase, so well done.<p>The optimizations are so-so. While I can see the benefits of the hardcoded constants, the other optimizations are hacks. And that has historically been the problem with PHP optimizations - they're all hacks. The engine needs rearchitecting to be fast, and all these hacks need to be removed, not more added.<p>Take for example that strlen is slow. The problem is that all function calls in PHP are slow. And if you looked at the function calling code, it's very obvious why. The correct solution is to make _all_ function calls fast, presumably by using some kind of inline cache, or just refactoring a ton of that crap out.<p>(Actually, someone introduced a patch to PHP-internals about two years ago to cache function calls somehow. I don't remember the exact details, but it was similar to the concept of an inline cache, perhaps storing a function cache struct in some bytecode or something. As I recall, it was denegrated as not being a full PIC. Sigh).<p>Finally, I really don't like the added functions. No problem with the functions themselves, just that adding functions to core PHP is not useful to anyone but the author. What if they clash with a user's function names? Why couldn't they just be implemented in user space? Etc. This is very much going on the wrong direction.<p>In the future, I'd like to see an effort like this go wild and make backwards incompatible changes like making the needle/haystack parameters consistent, but that's optimistic. (If they were to do it, phpcompiler.org could well be used to provide a 2to3-like too for doing the user-code porting automatically).<p>So overall, some good and some bad. If the OP focussed on making optimizations which improved the code base, removing more crap, and avoided adding "new" things, this would be really nice.

Good to see. It's about time PHP got forked even if experimentally.<p>It seems to me that you could fix a lot of the problems with PHP by breaking backwards compatibility.

Boo, deleted short tags. Why do people hate short tags again? I can't remember because &#60;? is not valid XML so there shouldn't be any problems with mixing php and xml... hmm... I wonder ....

I wonder if it wouldn't have been better to import the PHP source-tree first, then apply each patch one at a time/in a batch. That way applying these patches at a later date would have been easier.

I'm a long-time PHP user (since 1998) but I never really peered inside the discussions of the internals of PHP. Now that I'm more connected to others in the PHP world, what you see inside the mailing list for PHP internals is what I would label as obstructionism and an attitude that seems to imply that if you cannot code the requested changes yourself, don't even bother asking.<p>Lead, follow, or get out of the way are the only three choices available to any language.

I was hoping for more profound changes. I've never read PHP internals but I'm under the impression the opcode language is not 'jitable' because it's an unformal mess while even python and lua are getting there ... It seems that Opcode caching is the most you can get out of the language as is.

And in a true PHP fashion, the new functions follow at least two naming conventions. Cf. <i>str_random()</i> vs <i>strcut()</i><p>PHP has no vision, it draws no people with vision and suffers for it very much. I say it as someone working with it for historical reason.

So, are strings in PHP cstrings, or are they a length/address pair?

Might be not completely offtopic if I asked here: is there some reason array, resource and object were never folded into one type (object)? It seems like array and resource are kept separate just because it's done this way internally (with array and resource super classes). Why can't resources or array be native-code-backed objects like some modules in python?<p>It seems like many special cases were left over from old versions and the inertia prevents any change.

Minor nitpick given the scope of these additions, but his use of a boolean argument to enhance implode is not my favorite.<p><pre><code> implode(',', $array, true) </code></pre> A new function (or even leaving it the way it was) is far more readable.<p><pre><code> implode_keys(',', $array) implode(',', array_keys($array))</code></pre>

This should be the mainline version, a lot of good stuff especially the new array syntax.

Does anyone know if there are any benchmarks about this?

Mmm, string looping!