php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #31004 E_STRICT doesn't warn on assignment to nonexistent member variable
Submitted: 2004-12-07 08:30 UTC Modified: 2005-01-14 08:31 UTC
From: levi at alliancesoftware dot com dot au Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 5CVS-2004-12-07 (dev) OS:
Private report: No CVE-ID: None
 [2004-12-07 08:30 UTC] levi at alliancesoftware dot com dot au
Description:
------------
 If you use strict error reporting, and set an object member variable that does not exist no error is triggered.

 The point of strict error reporting is supposed to be to catch programming errors and ensure maximum future compatability -- shouldn't it report exactly this type of situation?


Note: Verified only with 5.0.3RC1 (The CVS copy was the closest in the list)

Reproduce code:
---------------
<?

error_reporting(E_ALL | E_STRICT);

class Object {
    var $property;
    function __construct() {
        $this->proper = 1; // missing the last two letters!
    }
}

$x = new Object();

?>

Expected result:
----------------

Should trigger an error

Actual result:
--------------
-

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-12 01:03 UTC] tony2001@php.net
It was never supposed to do so.
Reclassifying as documentation problem, as I doubt it will change ever.
 [2005-01-13 18:10 UTC] vrana@php.net
Purpose of E_STRICT is stated at http://php.net/errorfunc#ini.error-reporting : "STRICT messages will help you to use the latest and greatest suggested method of coding, for example warn you about using deprecated functions." There's nothing about issuing errors when working with undefined member variables.
 [2005-01-14 08:31 UTC] levi at alliancesoftware dot com dot au
My 2c worth -- I understand it won't get changed, but one can always hope :(

  What then is the purpose at all for the var keyword in a class definition if not to provide some structure?
  In an object oriented context, "the latest and greatest suggested method of coding" I would have thought meant declaring variables. I understand given PHP's historical development that this behaviour was perfectly fine in PHP3 (where objects are more akin to associative arrays than Java-style objects), but I would have thought given PHP5's move towards structured programming that variable declaration should be encouraged where possible. (ASP for example requires variable declaration even thought it is similarly loosely typed)

 In regard to vrana's comment, the documentation doesn't say those are the only things E_STRICT is limited to; there are certainly already errors other than deprecated functions that E_STRICT will report.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jun 28 04:01:30 2024 UTC