I have a class that inherits from a another class.
I am overloading one method; PHP screams about this.
How do I silence this message? It clutters my debug logs.
Declaration of
Dashboard_Abstract::factory() should
be compatible with that of
Abstract::factory()
class Abstract{
static public function factory($param){
...
...
}
}
class Dashboard_Abstract extends Abstract{
static public function factory($param1,$param2){
...
...
}
}
Look, fellow developers. There is a difference between errors and warnings:
means,
"Look, if you are new to this you
might be doing something wrong here,
If you are experienced, you might be
doing right, so we will let you, the
developer, decide."
So, why won't you let me decide?
Is it so bad to use all of a language abilities to the max, even if some think it is an error (although, obviously, it is not).
You can use the error_reporting() function to override it at runtime, and there's an identically named parameter in php.ini you can set to make the change permanent. However, warnings are there for a reason and generally you should fix your code instead of just silencing them.
Well, since it is a specialized class, altering the method signature should not trigger a warning. It doesn't in pure OOP languages. And E_STRICT is really a special kind of purposed warning message (trying to impose a non-semantic coding standard).
But anyway, there is an easy workaround for your case. You can make the method signature compatible by just making parameters optional in the overriding method:
class Abc {
static public function factory($param) { }
}
class Xyz extends Abc {
static public function factory($param1, $param2=NULL) { }
}
Notice the $param2=NULL in the overloading method signature. With this trick the more specialized class/object can still be used where a parent object was expected.
You might use an assert($param2!==NULL) within the method instead if it is required.
(The E_STRICT notice for eventually undefined parameters in your static factory methods -which are only ever used with explicit classnames- really makes no sense here. But won't get fixed http://bugs.php.net/bug.php?id=41461 in the php.net implementation.)
You're not overriding it correctly because the number of variables has changed. It will continue to yell at you about this, as it should. Keep the number of arguments the same, use default arguments if you have to.
You should fix the problem. If you have a child class overriding a method in a parent class, the signature of the method must be compatible. That means that it must have the same or greater visibility, the same staticity (?!) and the same number or fewer arguments.
Either Abstract should take two parameters, or Dashboard_Abstract should take one. I can't tell you which way round it should be without seeing what these classes actually do...
You shouldn't silence that message, instead you should make sure that the overriding method is compatible with the original one. If you need the overriding method to accept a different number of parameters, you could rewrite the original method to use a dynamic list of arguments - see http://php.net/manual/en/function.func-get-args.php
Related
Code beforehand fully valid code from 5.0.0 (without E_STRICT or E_DEPRECATED)
class A{
static public function b() {
}
public function c(){
$this->b();
}
}
$d = new A();
$d->c();
$d->b();
It's looks like inconsistent behaviour because you cannot use static properties from instance.
The PHP way is to steal and borrow from other languages whenever
possible ...
But I cannot find any programming language that supports similar behavior.
Why does PHP support it? What is the point of calling static methods as non-static?
Some explanation from support: Expected behavior
Actually, C++ and Java support this. It seems the PHP developers, after discussion, decided on implementation to match them.
After a bit of digging, I found this thread from February 2004, which is essentially their discussion about the implementation choices. Important tidbits from the discussion:
From Cristiano Duarte:
C++ allows $a->bar() when bar() is a static method (yes, it is called
in a static context there too).
IMO, there should be no error, warning or notice here.
I Agree. PHP is fine the way it is.
From Art:
Regardless of the final implementation, I think access to static methods and
static class variables should be consistent. Currently, you cannot access a
class variable via an object instance.
And for what it's worth, I see no reason why static methods cannot be called
from objects. Follow Java/C++ in this case.
Ultimately, a final decision From Wez:
Please drop this thread; we're not changing the behaviour of static.
It looks to me that it is just a syntax consideration here. Nothing here is inconsistent with the logic of static methods, it's still impossible to use $this in your static function, and therefore the function will not have access to instance properties or methods. It feels more like a shortcut than an inconsistency to me.
I have no use case of that, but I guess someone may find it useful with objects created with dynamic class names: you can still use the function even if you don't know it's class name.
I'm very familiar with OOP in C++ and Java and I'm new to it in PHP, afterall PHP claims to support OOP. I'm refactoring some codes given to me in my internship and I came across the following style of coding, in PHP.
<?php
class A {
public function echoVar(){
$this->__();
echo $this->var;
}
}
class B extends A{
function __(){
$this->var = 1;
}
}
$v = new B();
$v->echoVar();
Following my experience with C++ and especially Java, this wouldn't even try to compile, but the execution is fine in PHP. I understand that all languages aren't the same but why does PHP support this style. Is this style good or bad practices? how is this OOP?
With my knowledge, the following are what I think is wrong with this code.
var is not a defined attribute of the class B, and yet was accessed and given a value.
How/Why did super class A have access to method __ of subclass B without casting or abstraction.
I would ask how class A got access to the attribute var but the attribute itself was created out of magic. On a serious note, why did it have access to var.
I'm a OOP newbie in PHP, so please help me clarify these things.
This is an example of, uhm, not so great coding. First, I would suggest activating strict error reporting (E_ALL | E_STRICT | E_NOTICE).
If an class/object property which hasn't been declared before, is assigned a value, it is going to be created as public property of the object. However, with strict error reporting, you'd get thrown an E_NOTICE.
Although the __ belongs to the B class, it can be called from A, when B is instantiated. The method is not declared as public/protected/private, so it's public by default, therefore accessible by parents/children as well as from the outside.
Of course, this is generally poor coding style, at least A would demand the implementation of __ in child classes with the following line: abstract public function __();.
Last, but not least, the function name __ is against PHP conventions, as methods starting with two underscores are reserved.
I would describe PHP as a language that tends to make assumptions when things are unclear, whereas C++ and Java are languages that force you to explicitly write everything out, or else they will throw errors.
Question #1 - In PHP you do not explicitly need to declare class properties in order to be able to assign them later, as you have discovered. Obviously though, if you immediately tried to echo $this->var; inside a class without assigning it, it would be undefined.
Question #2 - So this one's a little weird, but basically, if you create a superclass from a subclass, and you call a method inside a method defined in the subclass, the superclass version will get called. So even though __() is not defined in A, it is in defined in B, so if you create an A object, and called echoVar(); you will get a message about the method __() is undefined, you can still call echoVar(); in an object of type B, as __(); is defined there.
Question #3 - Similar to #2, even when used in the subclass, the superclass version of variables will be used.
I personally would try to never use this style of coding, however. As I'm sure you're already aware, it's not a good idea to make a class dependent on its superclass like that. It would be better to explicitly declare these things.
As for how it is OOP, the code you posted is primarily using objects as opposed to free floating functions or lines of code.
In my company's codebase, i see functions used in both static and object context. For e.g. a class A has a function b() which is called both using A::b() and/or object_of_type_A->b(). I know this throws an error if strict is turned on. But I wanted to know if this is a bad practice and if yes, then why? Thanks for any answers.
Let me know if I don't make sense anywhere. I would be happy to clarify.
I'm not a php guy, but this sounds just like Java, where it's allowed but discouraged.
If it's static, I would strongly recommend only calling it in a static way. Otherwise it looks like it depends on the state of the object you're supposedly calling it on.
In Java the best example of this is Thread.sleep(). It's a static method which puts the current thread to sleep, always. But look at this code:
Thread t = new Thread(someTask);
t.start();
t.sleep(1000);
What does it look like that code is doing? It appears to be putting the other thread to sleep, whereas in fact it'll be the current thread that's sleeping. When you change it to a plain static call, it's more obvious:
Thread.sleep(1000);
That doesn't refer to t, so must be about the current thread.
Unless there's something specific to php where calling the static method via a variable gives you some sort of polymorphism, I suggest you stick to calling it in the static way. The fact that strict mode tells you to do this is a pretty strong hint, IMO :)
Here's some test code:
<?php
error_reporting(E_ALL | E_STRICT);
class Foo{
public function a(){
}
public static function b(){
}
}
$MyFoo = new Foo;
Foo::a(); // Strict Standards: Non-static method Foo::a() should not be called statically
Foo::b();
$MyFoo->a();
$MyFoo->b(); // No complaints
?>
PHP/5.3 warns about static calls to non-static methods, which is fine since they are subject to failure as soon as you want to access $this. But it does not complain about object context calls to static functions: there's nothing that can go wrong. This behaviour is documented:
Declaring class properties or methods
as static makes them accessible
without needing an instantiation of
the class. A property declared as
static can not be accessed with an
instantiated class object (though a
static method can)
[...]
Because static methods are callable
without an instance of the object
created, the pseudo-variable $this is
not available inside the method
declared as static.
So, as far as PHP is concerned, what you found in the code base is not wrong. However, I think it's slightly confusing.
There is 'currently' no harm in using it either way except of course when called as a static function you can't access the $this member.
The reason it errors in strict is because not writing your code to strict standards can result in errors occurring due to a lack of diligence. in the future it may also cause your code to break. a static function has no $this member and it may break parameter passing.
Play it safe only call static functions with A::b() type calls.
DC
Regarding accessing $this in a static function I found something a bit strange a while back (might be changed in later versions of PHP though, think I ran 5.2 or something).
You can read about it here but it's in swedish. But use google translate and it should be understandable.
http://www.phpportalen.net/viewtopic.php?p=560080#560080
Is there any advantage to using __construct() instead of the class's name for a constructor in PHP?
Example (__construct):
class Foo {
function __construct(){
//do stuff
}
}
Example (named):
class Foo {
function Foo(){
//do stuff
}
}
Having the __construct method (first example) is possible since PHP 5.
Having a method with the same name as the class as constructor (second example) is possible from PHP version 4 until version 7.
I agree with gizmo, the advantage is so you don't have to rename it if you rename your class. DRY.
Similarly, if you have a child class you can call
parent::__construct()
to call the parent constructor. If further down the track you change the class the child class inherits from, you don't have to change the construct call to the parent.
It seems like a small thing, but missing changing the constructor call name to your parents classes could create subtle (and not so subtle) bugs.
For example, if you inserted a class into your heirachy, but forgot to change the constructor calls, you could started calling constructors of grandparents instead of parents. This could often cause undesirable results which might be difficult to notice.
Also note that
As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor. This change doesn't affect non-namespaced classes.
Source: http://php.net/manual/en/language.oop5.decon.php
__construct was introduced in PHP5. It is the way you are supposed to do it now. I am not aware of any advantages per se, though.
From the PHP manual:
For backwards compatibility, if PHP 5 cannot find a __construct() function for a given class, it will search for the old-style constructor function, by the name of the class. Effectively, it means that the only case that would have compatibility issues is if the class had a method named __construct() which was used for different semantics
If you're on PHP5 I would recommend using __construct to avoid making PHP look elsewhere.
The main advantage I see for __construct, is that you don't have to rename your constructor if you change your class name.
Today, the accepted answer is obsolete.
Renaming classes is bad practice: you have to remember what and where to rename everytime you upgrade to newer version. Sometimes (like using Reflection or complex dependence structure) it can be impossible without radical refactoring. And this is accidental complexity you want to avoid. That's why namespaces were introduced into PHP. Java, C++ or C# don't use __construct, they use named constructor and there's no issue with them.
As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor. This change doesn't affect non-namespaced classes.
Example
namespace Foo;
class Test {
var $a = 3;
function Test($a) {
$this->a = $a;
}
function getA() {
return $this->a;
}
}
$test = new Test(4);
echo $test->getA(); // 3, Test is not a constructor, just ordinary function
Note that named constructors are not deprecated (PHP 5.5 today). However, you can't predict that your class won't be used in namespace, therefore __construct should be preffered.
Clarification about the bad practice mentioned above (for Dennis)
Somewhere in your code you could use ReflectionClass::getName(); when you rename the class, you need to remember where you used Reflection and check if the getName() result is still consistent in your app. The more you need to remember something specific, the more likely something is forgotten which results in bugs in the app.
The parents can't have control about all the classes in the world which depends on them. If allow_url_include is enabled, some other web might be using the class from your server, which may crash if you rename some class. It is even worse in compiled languages mentioned above: the library can be copied and bundled in other code.
There is no reason why to rename class:
if the class name conflicts, use namespaces
if the class responsibility shifts, derive some other class instead
In PHP classes in namespace, the method with the same name should be avoided anyway: intuitively it should produce an object created the class; if it does something else, why to give it the same name? It should be a constructor and nothing else. The main issue is that the behavior of such a method depends on namespace usage.
There is no issue with __construct constructors in PHP. But it wasn't the smartest idea to alter the named constructors.
The best advantage of using __contruct() instead of ClassName() is when extending classes. It is much easier to call parent::__construct() instead of parent::ClassName(), as it is reusable among classes and the parent can be changed easily.
In your example Foo::Foo is sometimes called a PHP 4 or old-style constructor because it comes from the days of PHP 4:
class Foo {
// PHP 4 constructor
function Foo(){
//do stuff
}
}
PHP 4 constructors will be deprecated but not removed in PHP 7. They will be no longer be considered as constructors in any situation in PHP 8. Future compatibility is definitely a big reason to not use this feature.
Well it has been a few years since this question was asked, but I think I have to answer this one still, because things has changed and for readers in the future I want to keep the information up to date!
So in php-7 they will remove the option to create the constructor as a function with the same name as the class. If you still do it you will get a E_DEPRECATED.
You can read more about this proposal (the proposal is accepted) here:
https://wiki.php.net/rfc/remove_php4_constructors
And a quote from there:
PHP 7 will emit E_DEPRECATED whenever a PHP 4 constructor is defined. When the method name matches the class name, the class is not in a namespace, and a PHP 5 constructor (__construct) is not present then an E_DEPRECATED will be emitted. PHP 8 will stop emitting E_DEPRECATED and the methods will not be recognized as constructors.
Also you won't get a E_STRICT in php-7 if you define a method with the same name as the class AND a __construct().
You can see this also here:
PHP 7 will also stop emitting E_STRICT when a method with the same name as the class is present as well as __construct.
So I would recommend you to use __construct(), since you will have less issues with this in the future.
In PHP 5 the advantage would be that performance would be better. It will look for a constructor by the name of __construct first and if it doesn't find that, it will look for constructors by the name of className. So if it finds a constructor by the name __construct it does not need to search for a constructor by the name className.
Forward compatibility. There's always a chance that legacy code that's left in the language for backwards compatibility's sake will be removed in a future version.
If there is methods __construct and SameAsClassName method then __construct will be executed, SameAsClassName method will be skipped.
I think that the main reason is that is the language convention.
You don't need to force a language to act like someone else.
I mean, in Objective-C you prefix the constructors with -init, for example. You can make your own constructor using your class name but why? Are ther some reason to use this schema instead of the language convention?
PHP, as we all know is very loosely typed. The language does not require you to specify any kind of type for function parameters or class variables. This can be a powerful feature.
Sometimes though, it can make debugging your script a painful experience. For example, passing one kind of object into a method that expects a different kind of object can produce error messages complaining that a certain variable/method doesn't exist for the passed object. These situations are mostly annoyances. More onerous problems are when you initialize one object with an object of the wrong class, and that "wrong object" won't be used until later on in the script's execution. In this case you end up getting an error much later than when you passed the original argument.
Instead of complaining that what I passed doesn't have a specific method or variable, or waiting until much later in script execution for my passed in object to be used, I would much rather have an error message, at exactly where I specify an object of the wrong type, complaining about the object's type being incorrect or incompatible.
How do you handle these situations in your code? How do you detect incompatible types? How can I introduce some type-checking into my scripts so that I can get more easily understood error messages?
Also, how can you do all this while accounting for inheritance in Php? Consider:
<?php
class InterfaceClass
{
#...
}
class UsesInterfaceClass
{
function SetObject(&$obj)
{
// What do I put here to make sure that $obj either
// is of type InterfaceObject or inherits from it
}
}
?>
Then a user of this code implements the interface with their own concrete class:
<?php
class ConcreteClass extends InterfaceClass
{
}
?>
I want ConcreteClass instances, and all future, unknown user-defined objects, to also be acceptable to SetObject. How would you make this allowable in checking for the correct type?
Actually for classes you can provide type hinting in PHP (5+).
<?php
class UsesBaseClass
{
function SetObject(InterfaceObject $obj)
{
}
}
?>
This will also work correctly with inheritance as you would expect it to.
As an aside, don't put the word 'object' in your class names...
as an addition to Eran Galperin's response you can also use the type hinting to force parameters to be arrays - not just objects of a certain class.
<?php
class MyCoolClass {
public function passMeAnArray(array $array = array()) {
// do something with the array
}
}
?>
As you can see you can type hint that the ::passMeAnArray() method expects an array as well as provide a default value in case the method is called w/o any parameters.
For primitive types you could also use the is_* functions :
public function Add($a, $b)
{
if (!is_int($a) || !is_int($b))
throw new InvalidArgumentException();
return $a + $b;
}
You see, there are multiple answers about type hinting. This is the technical solution. But you should also make sure that the whole design is sensible and intuitive. This will make type problems and mistakes more rare.
Remember that even these type failures will be thrown at runtime. Make sure you have tests for the code.
Even in the case you describe, your script will crash, complaining there is no method / attribute X on the object Y so you'll know where does this come from.
Anyway, I think that always try to prevent grew up programmers to pass the wrong object to a method is not a good time investment : you could spend it in documenting and training instead.
Duck typing and careful colleagues is what you need, not additional checks that will make you app more rigid.
But it may be a Pythonista point of view...
#Eran Galperin's response is the preferred method for ensuring the object you are using is of the correct type.
Also worth noting is the instanceOf operator - it is helpful for when you want to check that an object is one of multiple types.
You can set the error_reporting ini setting in your php.ini file or use error_reporting function to set it in run time