The more projects I work on, the less I like configurable language options.

Some libraries are written assuming <? is fine, some aren't. But god help you when you try to merge them in.

As PHP has grown older, less of these strange incompatibilities continue to be supported (safe mode, etc), and I'm thankful for that.

I'm not sure if this could be easily built into PHP, but per-directory options are supported by PHP (when on apache, via a .htaccess file). If you could turn on or off strong typing per directory (or, alternatively, per file much like JS's "use strict"), there wouldn't be much of a practical problem.

It could even be a function modifier.

Unlike static typing or const correctness or immutability, strong typing is a very local feature that doesn't "bubble" across your codebase once you start using it.

Allowing .htaccess comes with a performance hit (Apache has to scan the directory and all of its parents for a .htaccess file on every pageview) and should generally not be used unless strictly necessary.

Also the fact that he's basically reinventing "scandir" ;)

Theres an OOP way to do this now with DirectoryIterator and RecursiveDirectoryIterator.

http://php.net/manual/en/class.directoryiterator.php

One of the big problems with PHP seems to be the amount of "hidden" features that you don't generally stumble upon unless you dive through the docs, or get the right google search.

> Theres an OOP way to do this now with DirectoryIterator and RecursiveDirectoryIterator.

OT: Iterators aren't OO.

First of all they don't work with objects/methods: we're forced to write a for/while loop, which is procedural programming. This also prevents abstraction and composition. Functions like "array_map" don't have these problems.

Second, they break encapsulation since they not only expose their elements, they also expose their internal mechanisms like "next", "rewind", etc. Again, array_map and friends win here.

Third, since they're a massive case of 'sequential coupling' ( http://en.wikipedia.org/wiki/Sequential_coupling ), and since objects are passed by reference, we must ensure that nothing we call in our loop body upsets the ordering (eg. by performing its own loop across the same iterator). This destroys encapsulation and modularity, and makes polymorphism and concurrency dangerous.

Just because something uses the "class" keyword doesn't mean it's OO.

That's just a bad argument. Simple code that suddenly breaks because of the contents of a directory shouldn't be possible, whether or not said simple code is unnecessary because of a standard library function. The example stands, weak typing is a horrible vector for difficult-to-catch bugs.

> That's just a bad argument

It's not my only argument. Here's what I wrote on the blog's own comments:

> I agree with your points, but picking this line as an example of the language’s problems

> is a bit of a straw man:

>

> “while ( ($filename = readdir($dh)) == true) $files[] = $filename;”

>

> Code like this smells terribly.

>

> First of all it uses “==”. That operator should trigger a deprecated warning, since it’s

> never appropriate. Even if you want the coercion, it’s better to write it explicitly with

> things like (int) or intval().

>

> Next, it’s using “== true”, which is completely redundant since the “while” will interpret

> the value as a boolean anyway.

>

> Next, it’s performing assignment inside a condition, which is generally frowned upon.

> There’s potential to confuse “=” with “==” or “===”, it’s using a statement in the place of

> an expression and it performs side-effects (setting the $filename value).

>

> After all that, it’s just duplicating existing functionality anyway: you could just say

> $files = scandir($dh).

I whole-heartedly agree here. You really shouldn't have to implement workarounds to know you're comparing two integers, or two booleans. === feels like a workaround to me and the amount of times I've seen people forget the last = is high. That's probably my #1 gripe with PHP.

You should always use === unless you want problems.

Except when you want to deal with array keys, where numeric strings gets casted to ints...