Contributing Advent 1: Xdebug and hidden properties
Today starts the "contributing advent" with a nice bug from Xdebug. I can't possibly be fixing an issue every day, so I've started a while earlier.
This first contribution is for bug #987: "Hidden property names not shown". In PHP it is possible to convert an array to an object with:
<?php $a = (object) [ "hello", 4 => "mr.", -8 => "elephpant" ]; var_dump( $a ); ?>
Xdebug's standard HTML var_dump() as well as the CLI, the coloured CLI and the debugger interface DBGp all suffered from the same issues that numerical properties were not showing in output. For example the above would show:
class stdClass#1 (3) {
string(5) "hello"
string(3) "mr."
string(9) "elephpant"
}
After the committed fix, it now shows:
class stdClass#1 (3) {
public ${0} =>
string(5) "hello"
public ${4} =>
string(3) "mr."
public ${-8} =>
string(9) "elephpant"
}
As you can see, it uses {…} to show it is a special property.
The debugger interface allows properties to be retrieved through the property_get command. This command returns an XML document that looks like:
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="property_get" transaction_id="4">
<property name="$o" fullname="$o" address="" type="object" classname="stdClass" children="1" numchildren="6" page="0" pagesize="32">
<property name="key" fullname="$o->key" facet="public" address="" type="string" size="5" encoding="base64">
<![CDATA[dmFsdWU=]]>
</property>
<property name="1" fullname="$o->1" facet="public" address="" type="int">
<![CDATA[0]]>
</property>
</property>
</response>
With the fullname property ($o->1) an IDE can then make further requests to dive into the property information, with:
property_get -i 42 -n $o->1
Initially that did not work, and I thought I had to extend the parser with additional rules to differentiate between an associative key and a numerical key. I came up with using $o->{1} as in the var_dump() output from above, and then using a special case to fetch a numerical property with zend_hash_index_find() and the integer value in between { and } instead of the zend_hash_find() that I normally use. An hour later I had implemented this and then came to the conclusion that I could just use zend_symtable_find() — which handles both numerical indexes as strings as well as associate indexes as strings, greatly simplifying the implementation. The change for the debugging interface was not more than: https://github.com/xdebug/xdebug/commit/4d8d5b7092f134e6e5a51a0ea2e6932930a29da9#diff-07a70c2afd727f925169e8b30f1c72dcL455
After adding six test cases, the issues is now resolved.
Life Line
Specify whether crosswalks have tactile paving
Specify whether pedestrian crossings have markings
Determine whether amenities are inside buildings
Specify whether various amenities are covered
Specify leaf types
Specify whether kerbs have tactile paving
Determine the heights of kerbs
Specify whether public transport stops have tactile paving
Survey if places still exist
Missing
Survey opening hours
Specify width of opening
Specify street/place names to addresses
Specify what can be recycled in recycling containers
Specify type of recycling amenities
Determine roads lane count
Specify whether roads have lane markings
Specify whether there are cycleways
Specify road surfaces
Specify whether roads have sidewalks
Specify whether pedestrian crossings have islands
Specify whether pedestrian crossings have traffic signals
Specify whether there are crossings at intersections of paths and roads
Specify which way leads up for steps
Specify whether steps have handrails

Shortlink
This article has a short URL available: https://drck.me/adv1301-aen