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

111–120 of 137 posts

Re: PHP 7's new hashtable implementation

#111

Post by lern_too_spel »

sorokod wrote: post #61
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... )

And it doesn't needlessly restrict you to integer or string keys like this "best designed data structure."

Re: PHP 7's new hashtable implementation

#112

Post by Arnavion »

gsg wrote: post #97
esailija wrote: post #91

Earlier quoted context omitted.

I am not sure what you are even saying. My point is that if the most optimal way would result in some other iteration order, that would be the iteration order experienced by users and that it is just a coincidence that the most optimal way results in insertion order.

I'm saying that argument is wrong, because there is no efficiency loss due to different insertion orders mapping to the same hidden class. In fact there are efficiency advantages because more objects would pass through class-based guard checks into favourable paths. The only reason I can see to not do that is because it would lose iteration order. Sketch out an example of hidden class transitions and it should be cle…

By the way, JS runtimes used to have insertion order for enumerating properties long before the hidden class optimization or V8 was a thing. V8 was the first to break the insertion-order enumeration for some kinds of objects [1] and eventually other browsers followed suit, even those that don't do hidden classes.

[1] http://code.google.com/p/v8/issues/detail?id=164

Re: PHP 7's new hashtable implementation

#113

Post by bandushrew »

overgard wrote: post #110
bcheung wrote: post #107

You mean they are not using strlen as the hash function anymore? http://news.php.net/php.internals/70691

Wow, I constantly think that nothing about the horribleness of PHP can surprise me, and then Rasmus says something even more insane than his already insane statements. I mean choosing function names based on length because you didn't bother to write an actual hash function? AMAZING. Anyway I'm just going to leave this here because it's great fun: http://en.wikiquote.org/wiki/Rasmus_Lerdorf Some favorites: "There are…

>I mean choosing function names based on length because you didn't bother to write an actual hash function? AMAZING.

Context: "This was circa late 1994 when PHP was a tool just for my own personal use and I wasn't too worried about not being able to remember the few function names."

Re: PHP 7's new hashtable implementation

#114

Post by jrochkind1 »

vec wrote: post #87
rst wrote: post #68

Earlier quoted context omitted.

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

Yes, and I think I can safely say I've never used this feature (in either Ruby or PHP) for anything more serious than a code golf challenge. This might just be me, but I don't think an ordered hash is a particularly easy data structure to reason about. Almost all the code that I've seen depend on it in either language has been too clever by half.

I've used it when I want to parse query params from a URL into a hash, and then possibly modify them, and then write them back out to query params -- in the same order they came in, so the query params will be identical if I didn't end up modifying them, and identical but for what I modified otherwise, etc.

There are probably other analagous circumstances. Maybe even some I could think of that I've encountered.

Re: PHP 7's new hashtable implementation

#115

Post by scotty79 »

halflings wrote: post #47

Make sure you don't miss this part: > PHP uses hashtables for all arrays. However in the rather common case of continuous, integer-indexed arrays (i.e. real arrays) the whole hashing thing doesn’t make much sense. This is why PHP 7 introduces the concept of “packed hashtables”. > [...] We keep these useless values around so that buckets always have the same structure, independently of whether or not packing is used.…

> Let's hope they'll soon add that different separate type for arrays (or "fully packed hashtables" if they prefer :)).

Could be good as long as it can be inferred whether compiler should use it or not, without additional clutter in the code.

Re: PHP 7's new hashtable implementation

#116

Post by bzbarsky »

esailija wrote: post #69
bzbarsky wrote: post #34

Earlier quoted context omitted.

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.

Ah, good to know. SpiderMonkey is in the process of adding that right now.

Re: PHP 7's new hashtable implementation

#117

Post by ptx »

apinstein wrote: post #67
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', ));

Good find. But you could easily do it with lists and tuples in many other languages, for example in Python:

json = data.valuesForKeyPaths([('foo', 'path.to.foo'), 'bar', ('baz', 'path.to.baz')])

Re: PHP 7's new hashtable implementation

#118

Post by eCa »

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?

The suggestion was that a future release of Perl5 should be named Perl7. Perl6 is a "spunky little sister"[1] to Perl5, not the next evolution of Perl.

[1] http://perl6.org

Re: PHP 7's new hashtable implementation

#119

Post by aidos »

breuleux wrote: post #106
halflings wrote: post #45

Earlier quoted context omitted.

> I hate that many other languages, including C#, Ruby and Python, force me to choose between either an unordered map or a list of (key, value) tuples Another commenter mentioned Python's OrderedDict, and Ruby's hashtables are ordered (from 1.9+): https://www.igvita.com/2009/02/04/ruby-19-internals-ordered-... It looks like C# also has an OrderedDictionary class: http://msdn.microsoft.com/en-us/library/system.collect…

I think there is one reason to default to something ordered, which is that iterating through unordered hashmaps can be non-deterministic from one run to the other. For instance, if you hash by id, the same objects may be assigned different ids from a run to the next, meaning that the map will be iterated in a different order. If there is a bug that's sensitive to iteration order, it will not be reproducible and that…

If you've got bugs due to iteration order you have a whole other issue. If you know that iteration order is important, it should be explicit in the way you prepare/store/handle the data. If your code only works when you iterate in a specific order and you didn't deliberately define that order, it's only really working by accident.

Don't get me wrong, it's actually a bug I've run into in the past, and you're right, the non-deterministic issue makes it harder to debug. But when I discovered it I blamed myself for not being explicit with my constraints.

Re: PHP 7's new hashtable implementation

#120

Post by [deleted] »

breuleux wrote: post #106
halflings wrote: post #45

Earlier quoted context omitted.

> I hate that many other languages, including C#, Ruby and Python, force me to choose between either an unordered map or a list of (key, value) tuples Another commenter mentioned Python's OrderedDict, and Ruby's hashtables are ordered (from 1.9+): https://www.igvita.com/2009/02/04/ruby-19-internals-ordered-... It looks like C# also has an OrderedDictionary class: http://msdn.microsoft.com/en-us/library/system.collect…

I think there is one reason to default to something ordered, which is that iterating through unordered hashmaps can be non-deterministic from one run to the other. For instance, if you hash by id, the same objects may be assigned different ids from a run to the next, meaning that the map will be iterated in a different order. If there is a bug that's sensitive to iteration order, it will not be reproducible and that…

[deleted]
Post reply on HN