3 ms·

> It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash k

> It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash key actually exists, or whether it exists and its value is set to NULL. 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? (This is not a snippy rhetorical question, I'd be interested in a real world example.) 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. I also like that arrays being dictionaries gives me the ability to do foreach($array as $index=>$value) if I want, which is nicer than some other languages, though admittedly some dynamic languages do such things better. > Code that I'd write in Common Lisp or Perl that takes advantage of multiple inheritance and the composition it offers is a lot uglier in PHP when I have to hack around not having multiple inheritance. It leads to bigger and monolithic classes that you can't easily compose. This is a holy war, obviously, and you do get interfaces at least. It suffices to me to know that I do have some intelligent supporters on the side of disliking multiple inheritance and mixins very much. If you're one of the people who can be extremely productive building large programs in a Lisp style, much respect and power goes to you, and anyone has to concede that PHP will be too limiting in that case. > This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp etc. you can't easily run most PHP code persistently, so the execution model for most applications is to parse, compile and execute the application for each request. 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.

avar 16y ago
> 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.

avar 16y ago

> 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.