Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7's new hashtable implementation

nikic.github.io

Post reply on HN
Print view View original

61–70 of 137 posts

Re: PHP 7's new hashtable implementation

#61

Post by sorokod »

skrebbel wrote: post #41

This is probably not a popular opinion, but I believe that PHP's associative array is one of the best-designed data structures in programming languages. Its main distinguishing property, as mentioned in this article, is that values can be indexed by key, but are still iterated in the order they were set. This is "do what I want" in so many cases that it's just nuts. Sure, just as often it's just needless overhead, bu…

> values can be indexed by key, but are still iterated in the order they were set

Java's LinkedHashMap provides this as well ( http://docs.oracle.com/javase/7/docs/api/java/util/LinkedHas... )

Re: PHP 7's new hashtable implementation

#63

Post by nly »

> The hash returned from the hashing function (DJBX33A for string keys) is a 32-bit or 64-bit unsigned integer

I thought there was a big hooha about PHP and other dynamic languages using ill-suited hash functions and ultimately most runtimes moved to SipHash?

Re: PHP 7's new hashtable implementation

#64

Post by cesarb »

adunn wrote: post #7

This is great news. PHP doesn't have many structured data types, so arrays (aka maps) are basically used for everything. Any improvement to them will impact the entire application. It would be nice to have separate types for arrays and maps though. I don't understand why they were combined to begin with. Simplicity? Seems like there are more edge cases and gotchas the way things are now.

> It would be nice to have separate types for arrays and maps though. I don't understand why they were combined to begin with. Simplicity? Seems like there are more edge cases and gotchas the way things are now.

Combining arrays and maps in one type was the cause for a remotely exploitable vulnerability in Drupal this year, https://www.drupal.org/SA-CORE-2014-005.

I commented on that at https://lwn.net/Articles/618530/. Quoting from that comment:

"[...] most uses will treat it either as an array (list of items) or as a key/value store (map from key to value, or sometimes set of values), but rarely as both at the same time. [...] In this vulnerability, the programmer expected a sequence, and was handed a mapping. [...] all uses of a single variable should be consistent (never use a sequence method on a mapping variable or a mapping method on a sequence variable). As shown in this vulnerability, "foreach ($data as $i => $value)" is a mapping method; it should never be used on a sequence, even if it works."

Re: PHP 7's new hashtable implementation

#65

Post by esailija »

skrebbel wrote: post #41

This is probably not a popular opinion, but I believe that PHP's associative array is one of the best-designed data structures in programming languages. Its main distinguishing property, as mentioned in this article, is that values can be indexed by key, but are still iterated in the order they were set. This is "do what I want" in so many cases that it's just nuts. Sure, just as often it's just needless overhead, bu…

JS objects don't have the same property, whatever order you see from iterating JS objects is only a side effect of the standard hidden class optimization, not because there was intention of having a certain order. In fact if you mix integer keys (which are represented differently) you will not get the "expected" iteration order:

    var o = {
        key: 3,
        1: 4,
        value: 10,
        0: 2
    };
    Object.keys(o)
    ["0", "1", "key", "value"]
If iteration order was specified you couldn't do those optimizations, note how even PHP7 is still paying a lot for the iteration order: the 100k element array only takes roughly 25% of the memory in JavaScript. And what is it even for? How often do you even need to iterate integer keys in insertion order over value order?

Re: PHP 7's new hashtable implementation

#67

Post by apinstein »

skrebbel wrote: post #41

This is probably not a popular opinion, but I believe that PHP's associative array is one of the best-designed data structures in programming languages. Its main distinguishing property, as mentioned in this article, is that values can be indexed by key, but are still iterated in the order they were set. This is "do what I want" in so many cases that it's just nuts. Sure, just as often it's just needless overhead, bu…

I finally found a use for mixed string/int keys.

I have a routine that plucks key/value pairs out of one associative array and builds another, and allows you to rename the resulting key names at the same time. Using mixed keys allows you to be more terse if you don't want to change the name:

$json = $data->valuesForKeyPaths(array( 'foo' => 'path.to.foo', 'bar', 'baz' => 'path.to.baz', ));

Re: PHP 7's new hashtable implementation

#68

Post by rst »

skrebbel wrote: post #41

This is probably not a popular opinion, but I believe that PHP's associative array is one of the best-designed data structures in programming languages. Its main distinguishing property, as mentioned in this article, is that values can be indexed by key, but are still iterated in the order they were set. This is "do what I want" in so many cases that it's just nuts. Sure, just as often it's just needless overhead, bu…

Ruby 1.9.x and later (at least in MRI) also guarantee to iterate over hash elements in the order in which keys were inserted.

http://www.ruby-doc.org/core-1.9.3/Hash.html

Re: PHP 7's new hashtable implementation

#69

Post by esailija »

bzbarsky wrote: post #34
bhouston wrote: post #19

How does this compare to the optimized hashtable implementations in the various JavaScript runtimes? I imagine their requirements are similar?

First off, JavaScript runtimes (or at least V8 and SpiderMonkey, which are the ones I've looked at) don't convert their arrays to hashtables unless they really have to. If your array is not sparse and has no properties defined on it with non-integer names, then it's an actual array of values in memory. Past that, even if you start defining non-integer names you still store the integer-named properties in a contiguous…

doubles and SMis have been unboxed in arrays (the internal array that backs the integer key properties of an object) for a long time at least in V8.

Re: PHP 7's new hashtable implementation

#70

Post by esaym »

brvs wrote: post #15
Bahamut wrote: post #2

What happened to PHP 6?

It's out being almost as successful as Perl6 and Python3 :-) e: Actually wasn't there a blog post posted to HN suggesting Perl skip to 7 too?

Indeed:

http://blogs.perl.org/users/ovid/2013/02/perl-7.html

http://www.slideshare.net/andy.sh/perl7-light

https://www.youtube.com/watch?v=E_8bjsimLsk

Post reply on HN