Edit report at http://bugs.php.net/bug.php?id=44287&edit=1
ID: 44287 Updated by: [email protected] Reported by: jaap dot taal at gmail dot com Summary: mysql_fetch_object calls __construct too late -Status: No Feedback +Status: Feedback Type: Bug Package: MySQL related Operating System: * PHP Version: 5.2.5 Assigned To: mysql Block user comment: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: ------------------------------------------------------------------------ [2008-11-10 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2008-11-02 13:35:01] [email protected] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ ------------------------------------------------------------------------ [2008-03-25 13:30:23] jaap dot taal at gmail dot com Note that moving the initialization of the id field from the constructor to the declaration fixes this problem, i.e.: class tbl_content { var $id = null; var $content; function tbl_content() { // $this->id = null; } } However I still think that, from an object oriented perspective, the constructor should be called first thing after creating an object. The implementation of the mysql_fetch_object is wrong. ------------------------------------------------------------------------ [2008-03-25 13:23:57] jaap dot taal at gmail dot com The constructor of the object initializes the id variable to be null (which is needed in other cases). ------------------------------------------------------------------------ [2008-02-28 22:17:09] jaap dot taal at gmail dot com Description: ------------ I'm using the mysql_fetch_object's ability to create a custom object. The constructor of the object initializes the . The scripts simply gets all the data from the a table and uses mysql_fetch_object to create the objects. The id property however is not set, it is null. I think that the mysql_fetch_object function first creates an object setting properties and than it turns this object into an object of the specified type, calling the constructor in the proces. looking at the php source for mysql_fetch_object shows me that a hash is retrieved first: php_mysql_fetch_hash After that the hash is converted into an object: object_and_properties_init I think an object should be created calling its constructor and than after that is done, the properties should be set. Reproduce code: --------------- <?php /* USE test; DROP TABLE IF EXISTS `tbl_content`; CREATE TABLE `tbl_content` ( `id` int(11) NOT NULL auto_increment, `content` text, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; INSERT INTO `tbl_content` VALUES (1,'asdf1'),(2,'asdf2'),(3,'asdf3'); */ $link = mysql_connect('localhost', 'test', 'test'); mysql_select_db('test'); class tbl_content { var $id; var $content; function tbl_content() { $this->id = null; } } $result = mysql_query("SELECT * FROM tbl_content", $link); if (!$result) { die(mysql_error()); } while ($obj = mysql_fetch_object($result, 'tbl_content')) { var_dump($obj); } ?> Expected result: ---------------- object(tbl_content)#1 (2) { ["id"]=> string(1) "1" ["content"]=> string(5) "asdf1" } object(tbl_content)#2 (2) { ["id"]=> string(1) "2" ["content"]=> string(5) "asdf2" } object(tbl_content)#1 (2) { ["id"]=> string(1) "3" ["content"]=> string(5) "asdf3" } Actual result: -------------- object(tbl_content)#1 (2) { ["id"]=> NULL ["content"]=> string(5) "asdf1" } object(tbl_content)#2 (2) { ["id"]=> NULL ["content"]=> string(5) "asdf2" } object(tbl_content)#1 (2) { ["id"]=> NULL ["content"]=> string(5) "asdf3" } ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=44287&edit=1
