PHP 7's new hashtable implementation

Post by esailija » Tue, Dec 23, 2014, 4:53 PM UTC

gsg wrote: post #82

esailija wrote: post #77

Earlier quoted context omitted.

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.

Post by eCa » Tue, Dec 23, 2014, 4:57 PM UTC

einhverfr wrote: post #84

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…

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.

Post by dsp1234 » Tue, Dec 23, 2014, 6:14 PM UTC

nothrabannosir wrote: post #72

dsp1234 wrote: post #35

Earlier quoted context omitted.

Adding non-numeric keys does not remove an Array's "arrayness" in JavaScript var x = []; console.log(Object.prototype.toString.call(x)); //[object Array] x[0] = 1; console.log(x[0]); //1 x["test"] = 2; console.log(x["test"]); //2 console.log(Object.prototype.toString.call(x)); //[object Array] x.map //function map() { [native code] } var y = {}; console.log(Object.prototype.toString.call(y)); //[object Object] y.map…

His point was: x = [1]; x["test"] = 555; x.map(function (y) { return y; }); // [1] That's [1], not [1, 555]. You can access the array from the map interface, but not the other way around.

  var x = {};
  x[0] = 1;
  x.length = 1;
  x.map = Array.prototype.map;
  x.map(function(y) {return y;});
  //[1]

Post by gsg » Tue, Dec 23, 2014, 6:17 PM UTC

esailija wrote: post #91

gsg wrote: post #82

Earlier quoted context omitted.

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.

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.

  start with {} of hidden class 
  add .x, transition to hidden class  with field .x at 0
  add .y, transition to hidden class  with field .x at 0 and field .y at 1

  start with {} of hidden class 
  add .y, transition to hidden class  with field .y at 0
  add .x, transition to hidden class  with field .y at 0 and field .x at 1

  start with {} of hidden class 
  add .x, transition to hidden class  with field .x at 0
  add .y, transition to hidden class  with field .x at 0 and field .y at 1

  start with {} of hidden class 
  add .y, transition to hidden class  with field .y at 0
  add .x, transition to hidden class  with field .x at 0 and field .y at 1