By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,051 Members | 1,221 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,051 IT Pros & Developers. It's quick & easy.

Class constructor inheritance

P: n/a
I found an odd situation that probably isn't doing what is intended.

class A {
function A() {
// normal constructor for class1
}

function B() {
// a general purpose method
}
}

class B extends A {
// this class will inherit A::B as a constructor
}
Jul 17 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
tc*****@savageResearch.com (Tim Cadell) wrote in message news:<db**************************@posting.google. com>...
I found an odd situation that probably isn't doing what is intended.

class A {
function A() {
// normal constructor for class1
}

function B() {
// a general purpose method
}
}

class B extends A {
// this class will inherit A::B as a constructor
}


I'm not sure I understand what you are saying. If I understood you,
you are saying class B picks up class A's constructor. Why would that
be odd? That is how it works in Java, and, I would guess, most OOP
languages. The constructors each execute in the order of the class
hierarchy, starting at the top and working down to the subclass.

Or did I misunderstand you?
Jul 17 '05 #2

P: n/a
Hi Tim,
I found an odd situation that probably isn't doing what is intended.

class A {
function A() {
// normal constructor for class1
}

function B() {
// a general purpose method
}
}

class B extends A {
// this class will inherit A::B as a constructor
}

The inheritance of the construct will result, cause
your class B has not defined a Constructor.
If you like to change this you have to override the
inherited construcotr with your own version....
That like in C++ ? What is odd on that?

Kind Regards.
Karl Heinz
--
Dipl.Ing.(FH) Karl Heinz Marbaise | www.marbaise.org
Jabba Dabba Dooh ;-) | ICQ# 135949029

Jul 17 '05 #3

P: n/a
Karl Heinz Marbaise <kh********@gmx.de> wrote in message news:<c4*************@ID-68093.news.uni-berlin.de>...
Hi Tim,
I found an odd situation that probably isn't doing what is intended.

class A {
function A() {
// normal constructor for class1
}

function B() {
// a general purpose method
}
}

class B extends A {
// this class will inherit A::B as a constructor
}

The inheritance of the construct will result, cause
your class B has not defined a Constructor.
If you like to change this you have to override the
inherited construcotr with your own version....
That like in C++ ? What is odd on that?

But even if he has a constructor in class B, the constructor in class
A still executes as part of the construction of class B, yes?
Jul 17 '05 #4

P: n/a
> But even if he has a constructor in class B, the constructor in class
A still executes as part of the construction of class B, yes?


None of this is what he is observing.

First of all, the answer to the above question is no. If class B has a
constructor, and extends class A (which also has a constructor), then class
A's constructor *will* *not* be called when you create a B object, unless
you either

1) There is no constructor for class B
2) You explicitly call the constructor for A in the constructor for B

Now, what Tim was saying is this:

class Shape {
function Shape () {
echo "I am a shape!";
}

function Square() {
echo "I have sharp corners!";
}
}

class Square extends Shape{
// No constructor defined
}

Now, the class Square does not have constructor, so it inherits the parent
constructor, right? Wrong. It has a constructor, Square::Square(). Doing

$S = new Square();

would result in "I have sharp corners!" being output, but not "I am a
shape!"

NB: I have not actually tested this, I am just explaining what Tim was
saying. And it makes sense, based on what I know of PHP internals, that it
would be this way. In a hard core language, like C++, I doubt it would
behave like this. That is what he is observing.
Jul 17 '05 #5

P: n/a
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message
Now, what Tim was saying is this:

class Shape {
function Shape () {
echo "I am a shape!";
}

function Square() {
echo "I have sharp corners!";
}
}

class Square extends Shape{
// No constructor defined
}

Now, the class Square does not have constructor, so it inherits the parent
constructor, right? Wrong. It has a constructor, Square::Square(). Doing

$S = new Square();

would result in "I have sharp corners!" being output, but not "I am a
shape!"

That's the kind of bug that would leave me dazed for days. Like, the
other day I wrote two class methods with the same name, but different
signatures, and I assumed PHP would tell the difference based on the
signature. Turns out I was wrong, but it took me awhile to realize
what the problem was.
Jul 17 '05 #6

P: n/a
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message
news:Ut**************@nwrddc03.gnilink.net...
NB: I have not actually tested this, I am just explaining what Tim was
saying. And it makes sense, based on what I know of PHP internals, that it would be this way. In a hard core language, like C++, I doubt it would
behave like this. That is what he is observing.


I reproduced this behavior on PHP 4.3.4. Pretty weird. I know this was a
problem in PHP 3 but that was supposed to have been fixed a long time ago.
According to the manual, "A constructor is a function of the same name as
the class it is being defined in."

Jul 17 '05 #7

P: n/a
> That's the kind of bug that would leave me dazed for days. Like, the
other day I wrote two class methods with the same name, but different
signatures, and I assumed PHP would tell the difference based on the
signature. Turns out I was wrong, but it took me awhile to realize
what the problem was.


I thought PHP would give an error about redefining a function. What does it
actually do? Just use the first one?
Jul 17 '05 #8

P: n/a
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message news:<EA****************@nwrddc03.gnilink.net>...
That's the kind of bug that would leave me dazed for days. Like, the
other day I wrote two class methods with the same name, but different
signatures, and I assumed PHP would tell the difference based on the
signature. Turns out I was wrong, but it took me awhile to realize
what the problem was.


I thought PHP would give an error about redefining a function. What does it
actually do? Just use the first one?


It just used the last one, which wasn't the one I wanted.
Jul 17 '05 #9

P: n/a
> It just used the last one, which wasn't the one I wanted.

I think the only way to do this would be to check to see what variables were
passed (NB: if they get passed NULL, it will be the same as if they were not
passed at all - using isset() won't help :-/ ), then either do and if/else,
if/elseif/else, or switch() setup.
Jul 17 '05 #10

P: n/a
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message news:<Op*****************@nwrddc01.gnilink.net>...
It just used the last one, which wasn't the one I wanted.


I think the only way to do this would be to check to see what variables were
passed (NB: if they get passed NULL, it will be the same as if they were not
passed at all - using isset() won't help :-/ ), then either do and if/else,
if/elseif/else, or switch() setup.


The only way to do what? Do you mean a way to simulate class methods
of the same name that act differently depending on their signatures? I
suppose that is true, but it is hardly the same. You end up with,
complicated methods, with big switch statements, instead of small,
elegant class methods that only do one thing. I resorted to if()
statements a level up from where you suggest, at the point where I
decide which subclass to initialize. The subclasses can all have
methods of the same name, which act differently - at least this way
the methods stay relatively small, and do only one thing.
Jul 17 '05 #11

P: n/a
"lawrence" <lk******@geocities.com> wrote in message
news:da**************************@posting.google.c om...
I resorted to if()
statements a level up from where you suggest, at the point where I
decide which subclass to initialize. The subclasses can all have
methods of the same name, which act differently - at least this way
the methods stay relatively small, and do only one thing.


Interesting idea. Glad you came up with something that worked. :-)
Jul 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.