get_defined_vars() scope clarification

[CmsWares]

The manual for get_defined_vars() reads:

This function returns a multidimensional array containing a list of all defined variables, be them environment, server or user-defined variables, within the scope that get_defined_vars() is called.

However, I notice that superglobals like $_GET, $_POST, $_SERVER etc. are within a function's scope (right?), however they are only returned when called outside any scoping context. Calling get_defined_vars() inside a function only returns user-defined variables, if any. Investigating further, a scoping test shows that:

- function no_vars: array(0) { }
- function has_vars: array(1) { ["var"]=> int(1) }
- function has_args: array(1) { ["arg"]=> int(1) }
- anon function: array(0) { }
- anon function with var: array(1) { ["var"]=> int(1) }
- anon function with use(): array(1) { ["used"]=> int(1) }
- blank class: array(0) { }
- class with properties: array(0) { }
- static class with properties: array(0) { }
- no context: array(10) {
	 ["_GET"]=> array(0) { }
	 ["_POST"]=> array(0) { }
	 ["_COOKIE"]=> ...
	 ["_FILES"]=> array(0) { }
	 ["func"]=> object(Closure)#1 (0) { }
	 ["funcVar"]=> object(Closure)#2 (0) { }
	 ["used"]=> int(1)
	 ["funcUses"]=> object(Closure)#3 (1) { ["static"]=> array(1) { ["used"]=> int(1) } }
	 ["cBlank"]=> object(classBlank)#4 (0) { }
	 ["cProps"]=> object(classProps)#5 (3) { ["foo"]=> int(1) ["bar":protected]=> int(2) ["meh":"classProps":private]=> int(3) }
}

In keeping with the "returns variables explicitly available in a given scope" (and excluding superglobals) behavior, the results are mostly as expected. However, I find the following a bit anomalous:

• when called inside a class constructor, properties are not returned -- even though they are within scope
• when called in global scope, the properties of an object instance are however returned
• in global scope, superglobals $_SERVER and $_ENV (PHP 5.4+) are not returned

I think these behaviors should be mentioned explicitly in the manual, along the lines of:

• In global scope, a list of all defined variables, whether superglobals, command line arguments or user-defined variables
• In function scope, only a list of user-defined variables (both arguments and in-body definitions)
• In class/object method scope, does not return class/object properties;

[cmb69]

Thanks for careful examination and reporting the issue. Some notes:

when called inside a class constructor, properties are not returned -- even though they are within scope

No, the properties are not within scope; only $this is. Since $this is documented as pseudo variable, I don't think this is an implementation bug, but it should be mentioned in the docs.

when called in global scope, the properties of an object instance are however returned

Well, the documentation is misleading by mentioning a multidimensional array; actually, what is returned is an array where the keys are the variable names, and the values are the respective values of the variables, where get_object_vars() is used to retrieve the values of objects.

in global scope, superglobals $_SERVER and $_ENV (PHP 5.4+) are not returned

Indeed.

[CmsWares]

No, the properties are not within scope; only $this is.

Right indeed, true that. Still, agreed that a mention would be in place. On the note of $this, I see some user comments reporting that $this appears in the result in some contexts, however I'm unable to replicate on PHP 7/8; apparently a 5.x quirk.

Well, the documentation is misleading by mentioning a multidimensional array; ...

It's certainly not particularly clear there. Honestly documentation on this is a bit on the stub side. While we're at it, I'd like to call the grammar police on "be them environment, server or user-defined variables", is "they". Also it's really vague, there are standard superglobals that are almost invariably included that should be mentioned by name. Do "server" ,and "environment" here mean $_SERVER and $_ENV? What about $_SESSION, $_REQUEST, $_POST, $_GET, $_COOKIE, $_FILES?

Really though a more technical wording would be fine, documentation is not the place for waxing lyrical. We have these idiosyncrasies in the docs where one wonders what level of prose the dudes were after. I should like to submit a pull request for:

get_defined_vars() ... shall seize and convey such a names-for-keys arrangement, as would have for the contents of each key each variable hitherto user-ordained or of the yonder system's broad-gauging sort, save for a few and unbeknownst the reasons they're amiss, yet would neither sport erstwhile variables nor hoist to present the forthcoming, ...