So, the only thing I'm actually interested is: API for it stays the same? That is it's the same old "all in one" data structure with the same behavior for all standard functions, with all old gotchas left in place and no new added, right?
PHP 7's new hashtable implementation
81–90 of 137 posts
Re: PHP 7's new hashtable implementation
#82Earlier quoted context omitted.
> only a side effect of the standard hidden class optimization, not because there was intention of having a certain order Do you have a reference for this? I clearly recall a Lars Bak interview in which he says that adding a property .x and then .y results in an object of different hidden class than adding .y and then .x exactly because people want to rely on iteration order. (Might not apply to numeric keys, though.…
It results in different hidden class because the whole point is to be able to reference named fields by fixed offsets from the object location in memory (same as for example reading struct fields in C). If the order changes, so will the offsets too, so same names with different order must have different hidden classes. Integer keys are not practical to treat as fixed because they are used as array indices 99% of the…
I don't think your explanation makes much sense. Hidden classes describe the layout of objects: if two insertion orders produced the same hidden class, it would mean they have the same layout, with the same fixed field offsets.
The only difficulty I can see with doing that is that is insertion order.
Re: PHP 7's new hashtable implementation
#83Copied from /r/php (care of http://www.hhvm.rocks):
dev@aerilon ~/dev $ php --version
PHP 5.5.20-pl0-gentoo (cli) (built: Dec 22 2014 13:44:21)
dev@aerilon ~/dev $ hhvm --version
HipHop VM 3.5.0-dev (rel)
dev@aerilon ~/dev $ php memusage.php
13.97 MBs [14649088 bytes]
dev@aerilon ~/dev $ hhvm memusage.php
2 MBs [2097152 bytes]
Great job, PHP internals team...
Re: PHP 7's new hashtable implementation
#84This 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…
Perl used to let you do this, btw, but they moved away because apparently some denial of service issues were found regarding hashmaps, and so there are security reasons not to. I think you can tell Perl still you don't want that security and it will behave in this way. THere are other ways to do this only on some hashes but they have something of a performance penalty.
Re: PHP 7's new hashtable implementation
#85An important variable determining memory consumption is going to be the maximum bucket load factor. Does anyone know what it is as currently implemented?
Re: PHP 7's new hashtable implementation
#86Earlier quoted context omitted.
What are those called then? Wikipedia definition of primitive type is pretty vague. I don't think collections/containers can't be called primitive.
Collections are generally not primitives unless they are implemented in the language as primitives.
While I agree with you, Erlang for instance has collections as primitives (lists/tuples), but then offers more complex collections (such as gb_tree) as part of the stdlib.
Re: PHP 7's new hashtable implementation
#87This 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
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.
Re: PHP 7's new hashtable implementation
#88So, the only thing I'm actually interested is: API for it stays the same? That is it's the same old "all in one" data structure with the same behavior for all standard functions, with all old gotchas left in place and no new added, right?
This is only a change to the underlying implementation. Extension authors may need to update their code, but probably not in most cases.
There are no userland changes here.
Re: PHP 7's new hashtable implementation
#89> 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?
Can you provide a citation for "most"?
Re: PHP 7's new hashtable implementation
#90This 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've found one use-case for mixed-keys: parsing complex headers. For example: Link: ; rel=stylesheet; type=text/css [ [0] => [rel] => stylesheet [type] => text/css ] It doesn't come up very often.
This actually reminds me of what you get if you use named capture groups in PHP:
php > $link = 'http://example.com/';
php > preg_match('#http://(?P[^/]+)/#', $link, $matches);
php > print_r($matches);
Array
(
[0] => http://example.com/
[domain] => example.com
[1] => example.com
)