From: exaton at free dot fr
Operating system: WinXP SP2
PHP version: 5CVS-2005-01-13 (dev)
PHP Bug Type: SimpleXML related
Bug description: Confusion with XML nodes named as PHP keywords
Description:
------------
Note : I wish I could call this "remark" as opposed to "bug", because I
don't really suppose it can be solved, anyway.
The exact version of PHP used is the Jan 12 2005 18:14:35 5.0.4-dev Win32
snapshot.
When accessing object members, I am in the habit of putting spaces on
either side of the object/arrow operator "->" for clarity.
It is a known situation that with such practice, the right-hand argument
(the object member) had better not be named after a PHP keyword. For
example :
class A {
public $list;
public function __construct() {
$this -> list = 'value'; // (*)
}
}
Line (*) generates a parse error, unexpected T_LIST, expecting T_STRING or
T_VARIABLE or '{' or '$'.
That is easily resolved : it would extremely bad practice to name a member
thus anyway. But what of XML nodes seen as SimpleXML objects ?
<?xml version="1.0"?>
<root>
<list>item1, item2, item3</list>
</root>
$xml = simplexml_load_string/file(/* what is above */);
foreach ($xml -> list as $elemList) { // (**)
// manage the list, e.g. make it into an array...
}
Exact same problem as before on line (**), of course, because of how
SimpleXML gives access to child nodes.
The issue here is that I am not the one writing the XML file, defining its
XML Schema, etc. ; so I can no longer solve the problem with better naming
practice. And imposing PHP practice in PHP code is consistent : it seems
less so to impose PHP practice to an otherwise independant XML file.
Easiest workaround : drop the spacing on either side (or at least, the
right-hand side) of the object operator, and live up the ensuing slight
ugliness.
But might not something be done at a deeper level ? I imagine this crops
up for all reserved words, that the parser will see as special tokens
before considering that they might be object members.
But the thing is, I cannot think of any context in which the right-hand
argument of an object access might _want_ to be the PHP keyword, with the
functionnality induced.
I.e. is it possible for "$obj -> list" to mean anything with regard to
what "list" means for PHP ?
Same for the other reserved words as far as five minutes' pondering can
make out.
As I said in introduction, I don't expect it is really feasible to clear
this "bug", as in make the parser see the right-hand argument of a "->"
operation as a systematic object member and never imagine that it might be
a special token, but I would be interested in someone from PHP providing a
quick thought on this.
Thank you.
--
Edit bug report at http://bugs.php.net/?id=31536&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31536&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31536&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31536&r=trysnapshot51
Fixed in CVS: http://bugs.php.net/fix.php?id=31536&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=31536&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31536&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31536&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31536&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31536&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31536&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=31536&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=31536&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=31536&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31536&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=31536&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31536&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31536&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31536&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31536&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31536&r=mysqlcfg