nikic

Oh, thanks, now I understand!

Is the scale in the first image logarithmic?

Just using LC_ALL="C" would break people using some other language to write code. I personally strictly disagree with writing code in anything but English, but other people think it's okay to have Russian class names or something. Using LC_ALL="C" would make this impossible.

Could you be a little bit more specific?

What is crappy about the late static binging support for example?

Btw, you can bind and rebind $this as of PHP 5.4.

I don't know much about OpenGL ES in particular, but backwards compatibility arguments are very tricky in general.

On the one hand you have all the people maintaining legacy apps and not interested in improving their code. They'll scream at you for breaking BC. On the other hand you have other people complaining that the library sucks due to all the old stuff and why they don't just remove all the crap.

I noticed this in particularly in the context of PHP. People really hate some parts of the language (for good!) and commonly demand a big BC breaking release that fixes all the bad parts. But every time something is fixed (obviously breaking BC in some way) there is a big outcry about wtf the developers have been thinking and whether they are all braindead - well, the usual stuff.

So really, before you start calling people idiots because they didn't keep comparability with an older version (or here even a completely different version), think again. There probably was a lot thought put into the decision. It's not like people just say "Oh, let's drop this, just so everyone can change his code!"

This comment is wrong on just so many levels.

You seem to think that browser are less secure than running native software. This is totally absurd. And this blog entry shows exactly that. In order to bypass the advanced sandboxing techniques employed by modern browsers you have to build up complex chains of dozens of bugs.

This is very different with desktop software. Desktop software is protected far less than code running in the browser.

So the idea that running apps in the browser makes you more vulnerable than running native applications seems very unrealistic.

Also you seem to have the very nostalgic view that the web should be just static websites with a few links in between. This concept again seems completely absurd. From my point of view as a PHP programmer the dynamic web is pretty much the best thing that happened to mankind. It allows you to run software without having to install it. From everywhere. From the the point of view of the end user this is still true. Just look around. Look at Facebook, Twitter and stuff.

It may be a matter of taste, but I always considered this particular feature of == beneficial. In the normal case, it is what you need (in the context that most PHP applications deal with, namely communication over HTTP and with MySQL).

What is shown here is just a rare edge case that you should not normally encounter.

But I think that == has some other behaviors which are really detrimental. Like 0 == 'hallo world'. Sadly those can't be fixed due to backwards compatibility.

Please have a look at the comments by "jabakobob at gmail dot com" and myself ("nikic@php.net"). They explain why such behavior is actually good, in most cases.

Consider my mind blown. This is awesome.

> Recruitment secret weapon. It warms our hearts to see the look of incredulous joy on the face of a job candidate when we assure them “You heard right, we really don’t support IE.”

I can imagine that look so well...

The truth lies somewhere between a) and b).

I don't really know C well, as I'm mainly programming in PHP. Sure, I can read and write it, but I definitely don't know the details of the language (and yes, I'd consider that a detail as the only difference I know of is the behavior of sizeof).

The www.php.net mirror will only be rsynced tomorrow, for now use http://docs.php.net/manual/en/migration54.php instead to get infos about 5.4 features. It's a good bit more up to date.

PHP_CodeSniffer - as you already say - works with the source code at a token level. This is necessary, because it looks at the precise formatting of the code (like whitespace usage).

The parser is more for analyzers that are not interested in the precise formatting of the code, but want to look at the code from a higher level perspective.

For example, if you want to do control flow analysis and type inference working directly on the tokens would be really hard. An Abstract Syntax Tree makes this kind of work much easier, as you don't have to think about the tiny details of the language.

Only if you backported the max_input_vars fix. (Or if your distro did it for you in case you don't do your own compiles.)

You are exposing your Wordpress config in plain text, including DB password and various salts. Please make sure to change your DB password and the salts before you go back online.

I'm not really sure why you think that this only applies to frameworks and libraries. In my eyes this applies to any unit tested code. It is really hard or near impossible to test tightly coupled code. Or do you disagree about testing code in general?

Also I don't really understand why you think that factories are an antipattern. As I see it factories play an important role when using dependency injection.

I sure hope that a) is going to happen. PHP 5.2 is EOLed (i.e. no security fixes) for something like a year now. PHP 5.1 even longer.

It is somewhat risky to fundamentally change the hashing algorithm late in the release cycle (RC4). It is bound to cause problems. The ini-Option prevents the obvious threat without doing deep changes to the core.

Even if the HT hasn't reached the full size yet all elements will nonetheless collide: If the size currently is at 16 then 64 will still have a hash of 0, as will 128, etc. For 16 simply other values would additionally collide like 16, 32, 48, etc. These would stop being collisions as soon as the HT is resized, so we don't insert them.

A leading null byte is PHP's way to mark protected and private properties. See this: http://codepad.viper-7.com/TXMSbw

Even if the real C array contained a pointer to the last element in the LL (which it does not, it only points to the first) it would still be worst-case O(n): PHP has to check all elements in the LL to ensure that the element does not exist yet.

Consider this:

    $foo = array();
    $foo['bar'] = 'x';
    $foo['bar'] = 'y';

In this case the second set of the 'bar' index modifies an existing element in the linked list and is not appended as a new one.

Different hardware, different results. I ran my tests on a i3 CPU.

I don't know what a MacBook Air uses, but given that it's a notebook probably something slower :)

Actually this is not specific to PHP at all. Ruby just uses a different hashing algorithm so you need to set different keys to get these results.

This is a problem that hashtables have in general (unless they are randomized).

Incidentally it supports quite a bit more. Even the less powerful Perl Compatible Regular Expressions (PCRE), which are used by PHP, can also easily handle context sensitive grammars (type 1): http://stackoverflow.com/questions/7434272/match-an-bn-cn-e-...

I actually did most of my tests with PHP 5.4 and trunk binaries, but also tested PHP 5.3 and the numbers didn't change. PHP 5.2 used 8 bytes less, because the circular GC was introduced only in PHP 5.3.

By the way, you can test that yourself too. The codepad I posted the same on has a switch for PHP 5.2, 5.3 and 5.4, so you can easily see for yourself :)

Yep, I already got some comments on that. You are either using a 32 bit system or a 32 bit binary (at least I think that the binaries PHP distributes for Windows are compiled for 32 bit, so even if you are on a 64 bit Windows you'll still get 32 bit numbers).

The Windows number still is 8 bytes per element larger than the number I wrote (76 per element). This might have various reasons, one could be that it was compiled with head protection :)