PHP and OOP

[nrg_alpha]

That's what I though.. thus, since you didn't instantiate an object, I realized your sample would cause problems.

EDIT- Let me rephrase that.. just by the sample given, and the declaration Dog::bark();, I knew something wasn't right (lack of static declaration).

[Daniel0]

Hmm... not as far as I'm concerned.

 

Consider the following example:

class Parent
{
public function method() { /* ... */ }
}
class ChildA extends Parent { /* ... */ }
class ChildB extends Parent { /* ... */ }

 

Now if I say $obj->method() you cannot know if I'm talking about calling it on Parent, ChildA or ChildB. However, if I say ChildA::method() then you immediately know which class I refer to. You cannot see the name of the class when looking at a variable holding an instance of a class. That's why one would use the double colon notation even though the member you are referring to is not static.

[nrg_alpha]

Hmm... not as far as I'm concerned.

 

Consider the following example:

class Parent
{
public function method() { /* ... */ }
}
class ChildA extends Parent { /* ... */ }
class ChildB extends Parent { /* ... */ }

 

Now if I say $obj->method() you cannot know if I'm talking about calling it on Parent, ChildA or ChildB. However, if I say ChildA::method() then you immediately know which class I refer to. You cannot see the name of the class when looking at a variable holding an instance of a class. That's why one would use the double colon notation even though the member you are referring to is not static.

 

Right.. I understand that.. that's why $this acts as  'placeholder' if you will... a pseudo variable that represents what the object's name in question will be. So definitly, $this->method() works... (once an object is instantiated). But with regards to ChildA::method().. is this intended to call the method within the Parent class?

 

EDIT - I suppose what I am getting at is,(going back to your Dog example).. given you listed a class, then tried to invoke dog via Dog::bark(); here is what I am seeing:

 

class Mammal{
    var $blood;
    function __construct(){
        $this->blood = 'warm';
        echo$this->blood . "<br />\n";
    }
}

class Dog extends Mammal {
    function bark(){
        echo 'Woof!';
    }
}

$x = new Dog;
// $x->bark(); // will the next sample below work instead?
Dog::bark();

 

What's wrong with this picture?

[Daniel0]

But with regards to ChildA::method().. is this intended to call the method within the Parent class?

 

From the information given it could potentially have been overridden in ChildA. Parent::method() isn't declared final so the person who implemented ChildA would be free to do that.

 

Anyway, the PHP manual uses that notation as well. Example: http://php.net/manual/en/mysqli.query.php

[nrg_alpha]

See me EDIT in last post.. sorry..

 

EDIT - Ignore the garbage within the mammal class.. this was just for testing.. could be // whatever... instead..the mammal info isn't important.

[nrg_alpha]

 

From the information given it could potentially have been overridden in ChildA. Parent::method() isn't declared final so the person who implemented ChildA would be free to do that.

 

Anyway, the PHP manual uses that notation as well. Example: http://php.net/manual/en/mysqli.query.php

Ah, gotcha.. hadn't considered overrides.

[Rangel]

class Mammal{
    var $blood;
    function __construct(){
        $this->blood = 'warm';
        echo$this->blood . "<br />\n";
    }
}

class Dog extends Mammal {
    function bark(){
        echo 'Woof!';
    }
}

$x = new Dog;
// $x->bark(); // will the next sample below work instead?
Dog::bark();

 

What's wrong with this picture?

 

Nothing wrong there as you may found out yourself. coz

"The Scope Resolution Operator (also called Paamayim Nekudotayim) or in simpler terms, the double colon, is a token that allows access to static, constant, and overridden members or methods of a class."

 

Only thing is if you use :: on a non declared static method such as in your example IDEs  such as NetBeans won't give you the code hint "completition" of that specific method. It will presume you are working with instance method scope.

 

But this may not be that important for many blokes out there

[corbin]

Non-static methods should not be called statically.

[Rangel]

Non-static methods should not be called statically.

 

I totally agree with you mate, That is one reason i try to always keep consistent with my code and in my specific taste I barely, almost never, use instance classes. I like what static offers me.

 

In his particular case the method is being treated as overriden  coz nor static or final was defined in his bark() method. I guess that is why he was wondering -> vs ::

 

[corbin]

No, he was wondering because Daniel mentioned it in the form class::method when it wasn't declared as static.  (Things are often referred to in writing with :: even if they're not static.)

 

 

 

I have nothing against static stuff, it's just syntactically wrong to call a dynamic method statically.

 

 

(Well, PHP treats it as either a warning or error, but it's a no-no.)

[nrg_alpha]

@ Rangel

 

In my last example, there is something 'wrong' with that picture (but I just realized is that I didn't include the E_Strict error_reporting in that sample, which perhaps is one possible cause for confusion). When I test stuff locally, I always have it on. So to illustrate a cleaner sample like so:

 

error_reporting(E_ALL | E_STRICT); // keep this here to check that you code doesn't cough up warnings and / or errors.

class Dog {
    public function bark(){
        echo 'Woof!';
    }
}

Dog::bark();

 

The method will still be invoked.. but not without a juicy warning to go along with it.

 

Strict Standards: Non-static method Dog::bark() should not be called statically in C:\xampp\htdocs\deleteMe.php on line 31
Woof!

 

The previous snippet I provided would also issue that warning as well.. but if the error_reporting was missing (as is the case in that previous snippet), it would 'appear' to behave properly without any incident whatsoever. But obviously, in accordance to strict standards, this is not actually the case (nor recommenced, which was my whole point to begin with).

[Rangel]

righto mate, I see what you are saying now.

That is a good observation for ppl using instance classes to not lead themselves to this sneaky warning. Do ya think it would affect performance if one persists in this sort of confusing usage and do not ever realise the warnings?

[nrg_alpha]

Do ya think it would affect performance if one persists in this sort of confusing usage and do not ever realise the warnings?

 

That's a good and interesting question. Unfortunately, I don't have the answer to that. I used to build classes without E_STRICT on, and (with such warnings actually lurking in the background, unbeknownst to me) things 'seemed' to run fine (performance wise). But, should have seen the look on my face when I enabled E_STRICT error reporting only to be greeting with more warnings than I felt comfortable with. Since then, I always check with it on, just to make sure everything is good from a strict standards standpoint.

[Rangel]

But, should have seen the look on my face when I enabled E_STRICT error reporting only to be greeting with more warnings than I felt comfortable with.

 

LMFAO, I can just picture it ;

Yeah well I've seen Java ppl reporting this as a bug against php, the way we call static non static methods and the way around. In Java ie, it blows up right away.

But I also noticed that a lot of ppl from php see it as an "extra feature" .

 

I started a dilema discussion here: static VS instance, feel free to join us.

http://www.phpfreaks.com/forums/index.php/topic,241528.msg1126999.html#msg1126999

 

 

[corbin]

Hrmmm I wonder how PHP reacts if a statically called dynamic method references $this.  I would imagine it has to throw a fatal error.

[Daniel0]

IIRC it'll give a warning that complains about the fact that you are using $this outside an object context.

[corbin]

Hrmmm strange, I would think it would fatally error.