Page 2 of 4
Posted: Sat Jun 02, 2007 8:33 pm
by Christopher
Hockey wrote:Although it's polymorphic in nature it's not OOP polymorphism.
The call to $obj->foo() is clearly "OOP polymorphic" (there really isn't another kind) because the use of the object is dependent on its interface -- not its class. That's the key to polymorphism.
Hockey wrote:It's simply calling a function with a known interface by passing an object to function doStuff().
It's not calling the function that is polymorphic, it's the fact that it does not care what class $obj is, only that it has a foo() method.
Hockey wrote:Polymorphism is difficult to comprehend in the context of PHP as it relies pretty heavily on the concept of a "type" which PHP does not really
It is actually simpler to both comprehend and implement in PHP because the only check is if the method exists. Other languages like C++ have stricter definition requirements.
Posted: Sun Jun 03, 2007 7:16 am
by abalfazl
Hello
Getting more polymorphism
Interfaces give you more polymorphism than singly inherited families of classes, because with interfaces you don't have to make everything fit into one family of classes. For example:
Code: Select all
interface Talkative {
void talk();
}
abstract class Animal implements Talkative {
abstract public void talk();
}
class Dog extends Animal {
public void talk() {
System.out.println("Woof!");
}
}
class Cat extends Animal {
public void talk() {
System.out.println("Meow.");
}
}
class Interrogator {
static void makeItTalk(Talkative subject) {
subject.talk();
}
}
Given this set of classes and interfaces, later you can add a new class to a completely different family of classes and still pass instances of the new class to makeItTalk(). For example, imagine you add a new CuckooClock class to an already existing Clock family:
Code: Select all
class Clock {
}
class CuckooClock implements Talkative {
public void talk() {
System.out.println("Cuckoo, cuckoo!");
}
}
Because CuckooClock implements the Talkative interface, you can pass a CuckooClock object to the makeItTalk() method:
Code: Select all
class Example4 {
public static void main(String[] args) {
CuckooClock cc = new CuckooClock();
Interrogator.makeItTalk(cc);
}
}
With single inheritance only, you'd either have to somehow fit CuckooClock into the Animal family, or not use polymorphism. With interfaces, any class in any family can implement Talkative and be passed to makeItTalk(). This is why I say interfaces give you more polymorphism than you can get with singly inherited families of classes.
Is it possible build polymorphism in PHP by interface?
Posted: Sun Jun 03, 2007 7:28 am
by feyd
Of course it is.
Posted: Sun Jun 03, 2007 7:52 am
by Jenk
arborint wrote:Jenk wrote:Polymorphism is the ability for an object to adapt to it's environment. ... AdoDB is an example of polymorphism in the real world - you provide the DB type at instantiation and it will behave the same for any DB it supports.
That's
what, but you don't explain
how. The example given above does (as does you AdoDB example) -- polymorphic objects share the same properties and methods even though they are not the same class.
What you have demonstrated is simply interfacing, what the "shape" examples provide is polymorphism in it's simplistic form:
Code: Select all
class Shape
{
var $sides;
function Shape ($sides)
{
$this->sides = $sides;
}
function whatAreYou ()
{
switch ($this->sides)
{
case 1: echo "I am a circle."; break;
case 3: echo "I am a Triangle."; break;
// etc.
}
}
}
That, is polymorphism.
Posted: Sun Jun 03, 2007 8:31 am
by jayshields
To me polymorphism just means having many forms.
You can overload a method or override it.
Overloading is when you provide multiple methods of the same name in the same class but they take different parameters.
Overriding is when a subclass provides a method with the same name and same parameters as a method already provided from the superclass.
Posted: Sun Jun 03, 2007 8:41 am
by feyd
PHP doesn't support overloading, just overriding.
Posted: Sun Jun 03, 2007 8:51 am
by jayshields
feyd wrote:PHP doesn't support overloading, just overriding.
Sorry - I wasn't being language specific, probably should've mentioned that.
Posted: Sun Jun 03, 2007 1:53 pm
by Ambush Commander
What you have demonstrated is simply interfacing, what the "shape" examples provide is polymorphism in it's simplistic form: (snip) That, is polymorphism.
Confused now: I thought polymorphism's purpose was to get rid of those switch statements by having a distinct subclass for each possible object...
Posted: Sun Jun 03, 2007 2:12 pm
by feyd
Ambush Commander wrote:Confused now: I thought polymorphism's purpose was to get rid of those switch statements by having a distinct subclass for each possible object...
Provided they can all operate (at least partly) from the same interface, that's polymorphism. So yeah, you're thinking right.
Posted: Sun Jun 03, 2007 2:43 pm
by Christopher
Jenk wrote:Code: Select all
class Shape
{
var $sides;
function Shape ($sides)
{
$this->sides = $sides;
}
function whatAreYou ()
{
switch ($this->sides)
{
case 1: echo "I am a circle."; break;
case 3: echo "I am a Triangle."; break;
// etc.
}
}
}
That, is polymorphism.
At this point I have to emphatically say that I completely disagree with you. That example is not any kind of polymorphism that I know of. This is:
Code: Select all
class Triangle
{
function myName()
{
echo "I am a Triangle.";
}
}
class Circle
{
function myName()
{
echo "I am a Circle.";
}
}
class Shape
{
var $shape;
function Shape ($shape)
{
$this->shape = $shape;
}
function whatAreYou ()
{
$this->shape->myName();
}
}
There is polymorphism of parameters, variable type, return value, operators, and OOP. In all cases the
interface looks the same, but the internal operation is different. This discussion and the polymorphism most pertinent to us is as it relates to OOP.
Wikipedia -
"...polymorphism is the ability of objects belonging to different types to respond to method calls of methods of the same name..."
Webopedia - "
More specifically, it is the ability to redefine methods for derived classes. For example, given a base class shape, polymorphism enables the programmer to define different area methods for any number of derived classes, such as circles, rectangles and triangles. No matter what shape an object is, applying the area method to it will return the correct results."
Posted: Sun Jun 03, 2007 4:15 pm
by alex.barylski
arborint is correct.
Polymorphism in PHP is how he demonstrated. And yes, PHP is actually easier to comprehend because there is *nothing* to understand it's all handled for you automagically.
Consider the example:
Code: Select all
class Instrument{
function play(){ echo 'Instrument::Play()'; }
}
class Wind extends Instrument{
function play(){ echo 'Wind::Play()'; }
}
class Percussion extends Instrument{
function play(){ echo 'Percussion::Play()'; }
}
function tune(Instrument $i)
{
$i.play();
}
tune(new Percussion()); // Play a percussion
tune(new Wind()); // Play a wind
Notice in the function
tune() the argument type is of the base class
"Instrument". This is essential because you want the function to be able to accept *any* derived type of Instrument. If it was of type
"Percussion" the function
tune() would only be able to play percussion instruments which is NOT polymorphic. The historical problem with the aboce code is that, the methods of that type of object would be called, not the intended class method (of the derived classes). This is the problem polymorphism was introduced to solve.
The above code, when compiled in a language such as C++ the output is not what you would expect.
Output from above code:
Code: Select all
Instrument::Play()
Instrument::Play()
Because of
early binding. You usually need to explicitly indicate which functions are "virtual" via a simple function modifier and this makes that function or the object "polymorphic".
It is the late, dynamic or runtime binding of a function call that *is* the essence of polymorphism in OOP. PHP Does all this for you, so how did this disscussion even start?
Cheers

Posted: Sun Jun 03, 2007 5:40 pm
by Christopher
Hockey wrote:And yes, PHP is actually easier to comprehend because there is *nothing* to understand it's all handled for you automagically.

Hockey rightly points out that in languages like PHP -- polymorphism is done "automagically" for you many places. You can mix strings, floats and integers with impunity in mathematical equations, you can pass or return any type of value from any function, you can call a method by name in any object free of inheritance restrictions. Every PHP program uses "automagical" polymorphism as a matter of course.
The idea is that we are free of the drudgery of our predecessors so that we can spend more of our time focused on solving the problem rather than solving the implementation.
Posted: Sun Jun 03, 2007 5:57 pm
by Jenk
:shrug: that's what I've always called just plain and simple interfacing. Polymorphism has always been, to me, for the object to be able to adapt autonomously, not simply use a different object with the same interface entirely.
Posted: Sun Jun 03, 2007 7:52 pm
by alex.barylski
Jenk wrote::shrug: that's what I've always called just plain and simple interfacing. Polymorphism has always been, to me, for the object to be able to adapt autonomously, not simply use a different object with the same interface entirely.
Well both are right. My confusion lied in the fact that I wasn't aware PHP supported automatical polymorphic behavior. Looking at the code example above provided by Ambush under a compiled environment would yield the wrong results, calling the base class
play() instead of the actual argument type, unless you somehow used a hardcoded switch statement inside the base and cast the type to the derived type.
It's that hard-coding that is anti-polymorphic, which is what polymorphism (what you are saying) is actually doing; again PHP does this automagically (aka: functions as expected).
My understanding of polymorphism stems from C++ where you need to explicitly indicate which functions are virtual. Which in a compiled/linked environment makes sense. Because PHP is loosely typed and natively supports polymorphism, these details are hidden from the developer and so you wouldn't ever need to learn about v-tables and dynamic binding. Which is why I think this disscussion has gone the way it has.
Point is, you are right on with your definition, but so was Ambush with his example (under the context of PHP).
Cheers

Posted: Sun Jun 03, 2007 8:25 pm
by Christopher
Jenk wrote::shrug: that's what I've always called just plain and simple interfacing. Polymorphism has always been, to me, for the object to be able to adapt autonomously, not simply use a different object with the same interface entirely.
Actually I have learned more about polymorphism being an annoying, argumentative pain in the ass than I would have ever learned on my own -- so thanks.
I also think that you may be thinking of one of the non-OOP meanings of the term. Honestly I am mainly familiar with the OO type. But because polymorphism can be of parameters, variable type, return value, operators, etc. what you are thinking of probably falls under one or more of those. And because polymorphism is one of the essential ingredients of OOP languages, each has implemented there own support and restrictions of it. The examples in each language are different because of this.