> That's weird, and does seem like a wart. But is this really a problem in practice that leads to performance difficulties in real code? Here's some code I wro

> That's weird, and does seem like a wart. But is this really a problem in practice that leads to performance difficulties in real code? Here's some code I wrote in 2005 that ran into this issue: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/10549 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/10549 > It seems to me that if I'm using a PHP dictionary as an array, I'd know the length, and thus I'd be guaranteed that any access exists. The use case is the common idiom of populating a hash, and then iterating other hashes and checking if their keys exist in the original. In the example above I was loading ~50 files with 1000 key hashes each to check if there were any leftover translation strings in the translated files that weren't in the English original. Because the values could never be NULL I could get away with not using array_key_exists() which reduced the runtime from 60 to 2 seconds. But it's pretty silly that the core datastructures of the language have pitfalls like these. >> This is actually a major problem [...] > Agreed, and it is a huge pain when you want to do something after a request but yet you don't want to tie up the user in the mean time. > I'm not sure I'd want PHP to be a language that makes it easy to have a persistent execution model though; that simplicity (and restriction) is one of the things that has made the language so popular and scalable. PHP's model usually works fine for the kind of web-based problems it's intended for. In some ways, especially the built-in template language. But overall I think PHP as a isn't simple or newbie friendly at all. Its main advantage was that it offered a really simple execution model + Apache module. Which ISPs and others could easily offer along with MySQL, with little administration time compared to offering equivalent shell services. It was also was one of the first to have friendly online documentation with lots of syntax highlighted example code, and comments where people could submit more examples. But as a language it was never very competitive, and due to some of the tradeoffs made PHP never acquired a real community of module writers and re-usability. Thus most large PHP code bases end up being big balls of mud compared to equivalent code written with Catalyst, Django or even Rails. These days it seems to be mostly heading for being a worse Java with more bugs. Unless you have existing code in PHP other languages are probably a better fit for web applications these days.