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 pitches are lit
Survey whether benches have backrests
Specify what can be recycled in recycling containers
Specify type of recycling amenities
Survey postbox collection times
Determine whether any glass or just glass bottles can be recycled here
Specify whether bicycles can be charged at charging stations
Specify whether pedestrian crossings have islands
Specify whether pedestrian crossings have traffic signals
Specify parking types
Specify bicycle parking types
Add whether public transport stops are lit
Specify whether public transport stops have tactile paving
Determine the heights of kerbs at crossings
Specify whether roads have lane markings
Specify whether there are cycleways
Specify bollard types
Determine the heights of kerbs
Specify whether kerbs have tactile paving
Specify bicycle parkings covers
Survey if places still exist
Specify road surfaces
Specify whether crosswalks have tactile paving
Specify street/place names to addresses

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