|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2014-12-12 17:43 UTC] pedronaroga at gmail dot com
Description:
------------
Just recently I came up with the following E_STRICT report:
Strict standards: Declaration of Portal_IndexController::getUsuarioLogado() should be compatible with Sicneo\Controller\Action::getUsuarioLogado($fields = NULL).
I got very confused when I checked my code and saw that Sicneo\Controller\Action did not have a 'getUsuarioLogado' function. After a couple of minutes, I found out that Portal_IndexController was using a trait that had already defined a 'getUsuarioLogado' function, with the default `null` value to a `$fields` parameter.
The strict message should point to the trait instead of pointing out to the parent class.
Test script:
---------------
trait MyTrait {
public function myFunction($test = null) {}
}
class MyParentClass {
}
class MyChildClass extends MyParentClass {
use MyTrait;
public function myFunction() { }
}
$obj = new MyChildClass;
$obj->myFunction();
Actual result:
--------------
Strict standards: Declaration of MyChildClass::myFunction() should be compatible with MyParentClass::myFunction($test = NULL) in [...]
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Fri Apr 19 02:01:29 2024 UTC |
> The strict message should point to the trait instead of pointing > out to the parent class. No. Traits are more or less runtime assisted copy&paste reuse, so the method is conceptionally defined on the class using the trait. Consider renaming, e.g. <?php trait MyTrait { public function myFunction($test = null) {} } class MyParentClass { use MyTrait {MyTrait::myFunction as myOtherFunction;} } class MyChildClass extends MyParentClass { public function myOtherFunction() {} } ?> In this case reporting MyTrait::myOtherFunction() as being incompatible would be even more confusing.