 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jim Rowell
Guest
|
 Posted: Tue Dec 16, 2003 2:54 am Post subject: Virtual/Override/Reintroduce |
 |
|
Could someone please tell me if the following statements are correct? This
is what I have concluded from my reading but I have a suspicion that I'm
missing (or adding) something.
1) The only reason to declare methods as Virtual is so that descendent
classes have the option of overriding them. If the descendent methods will
be reintroduced (hiding the ancestor method), then Virtual offers neither
benefit nor harm.
2) The only reason to override an ancestor method is so you can call
Inherited from within the descendent method. If you don't intend to call
Inherited from within a descendent method, the descendent method should be
declared with Reintroduce rather than Override (for faster execution).
Am I on target?
Jim Rowell
|
|
| Back to top |
|
 |
Wayne Niddery [TeamB]
Guest
|
| Posted: Tue Dec 16, 2003 4:34 am Post subject: Re: Virtual/Override/Reintroduce |
|
|
Jim Rowell wrote:
| Quote: |
1) The only reason to declare methods as Virtual is so that descendent
classes have the option of overriding them. If the descendent methods
will be reintroduced (hiding the ancestor method), then Virtual
offers neither benefit nor harm.
|
Basically yes. However overriding is common, reintroducing is rare - you
need to know *why* you want to reintroduce the same method rather than
overriding it.
| Quote: | 2) The only reason to override an ancestor method is so you can call
Inherited from within the descendent method. If you don't intend to
call Inherited from within a descendent method, the descendent method
should be declared with Reintroduce rather than Override (for faster
execution).
|
No. An ancestor method does not need to be virtual in order to call it from
a descendant using inherited. Calling inherited is simply the way for
descendants to take advantage of ancestor code and has nothing to do with
the purpose of virtual methods.
The purpose of virtual methods is polymorphism. Polymorphism is the ability
to call a method of a class when you do not know the specific type of that
class, and the correct method will be called.
The classic (overused?) example:
TShape = class
x, y: integer;
procedure Paint; virtual; // paints a point
end;
TSquare = class(TShape)
len: integer;
procedure Paint; override; // paints a square frame
end;
TCircle = class(TShape)
radius: integer;
procedure Paint; override; // paints a circle frame
end;
TFilledSquare = class(TSquare)
color: TColor;
procedure Paint; override; // paints a square and fills it
// in this case only, Paint would likely call the ancestor's (TSquare)
Paint
end;
Without polymorphism, the only way I could paint each of the above shapes is
to have a variable of the correct type. E.g. I could declare a variable of
type TShape, create an instance and call Paint, and it would correctly paint
a point. But I could not use that same variable to paint a square, I would
have to have a separate variable of type TSquare to do that. Polymorphism
allows me to do this:
procedure PaintShape(shape: TShape);
begin
shape.Paint;
end;
procedure PaintAll;
var shape: TShape;
begin
shape := TShape.Create;
PaintShape(shape); // or just call shape.Paint here
shape := TSquare.Create;
PaintShape(shape); // or just call shape.Paint here
shape := TCircle.Create;
PaintShape(shape); // or just call shape.Paint here
shape := TFilledSquare.Create;
PaintShape(shape); // or just call shape.Paint here
end;
The point here is that I can pass any of these shape types to a method that
only knows about TShape and none of the others, yet that method can call
Paint and the *correct* method will be called, not necessarily TShape's
Paint method.
That's what virtual makes possible - and what makes Delphi possible; why
it's is able to create instances and call methods of your descendant form
types even though the Delphi code that creates those forms knows nothing
about your descendants.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"It is error alone which needs the support of government. Truth can
stand by itself." - Thomas Jefferson
|
|
| Back to top |
|
|
Jim Rowell
Guest
|
| Posted: Tue Dec 16, 2003 5:01 am Post subject: Re: Virtual/Override/Reintroduce |
|
|
Good explanation. Better than 2 books have done so far. :)
Thanks Wayne
Jim
|
|
| Back to top |
|
|
Tony J Hopkinson
Guest
|
| Posted: Tue Dec 16, 2003 8:18 pm Post subject: Re: Virtual/Override/Reintroduce |
|
|
On Mon, 15 Dec 2003 21:54:30 -0500, "Jim Rowell" <1@2.com> wrote:
| Quote: | Could someone please tell me if the following statements are correct? This
is what I have concluded from my reading but I have a suspicion that I'm
missing (or adding) something.
1) The only reason to declare methods as Virtual is so that descendent
classes have the option of overriding them. If the descendent methods will
be reintroduced (hiding the ancestor method), then Virtual offers neither
benefit nor harm.
2) The only reason to override an ancestor method is so you can call
Inherited from within the descendent method. If you don't intend to call
Inherited from within a descendent method, the descendent method should be
declared with Reintroduce rather than Override (for faster execution).
Am I on target?
Jim Rowell
As I far as I can make out the only reason for reintroduce is that |
it's too costly to go back and rework the ancestor component and all
it's descendants and their sibings, because you now want to do
something that while reasonable was not envisioned in the original
design. If it is n't reasonable then it's a hack in my opinion.
|
|
| Back to top |
|
|
Gerhard Venter
Guest
|
| Posted: Tue Dec 30, 2003 10:44 pm Post subject: Re: Virtual/Override/Reintroduce |
|
|
You had me puzzled with your explanation and on my understanding of it so I
went and read up again about it in the "Object Pascal Language Guide" (which
I have done many times in the past if I wonder about something) that comes
with Delphi.
If I can summarize it:
1. You have a virtual method declared (procedure MethodA; virtual;) for a
class.
2. If you re-declare MethodA in a descendant class but without the OVERRIDE
keyword then you HIDE MethodA without overriding it. If you call MethodA
from an instance of the descendant class then it will execute MethodA from
the ancestor class as both methods exists in the descendant class.
3. By using REINTRODUCE you ONLY suppresses compiler warnings that you are
about to hide a previously declared virtual method. So the purpose of
reintroduce is to hide an inherited virtual method with a new one.
So use override if you mean overriding otherwise you intend hiding in which
case you use reintroduce.
That is how I understands it.
Regards
Gerhard Venter.
"Wayne Niddery [TeamB]" <wniddery (AT) chaffaci (DOT) on.ca> wrote
| Quote: | Jim Rowell wrote:
1) The only reason to declare methods as Virtual is so that descendent
classes have the option of overriding them. If the descendent methods
will be reintroduced (hiding the ancestor method), then Virtual
offers neither benefit nor harm.
Basically yes. However overriding is common, reintroducing is rare - you
need to know *why* you want to reintroduce the same method rather than
overriding it.
2) The only reason to override an ancestor method is so you can call
Inherited from within the descendent method. If you don't intend to
call Inherited from within a descendent method, the descendent method
should be declared with Reintroduce rather than Override (for faster
execution).
No. An ancestor method does not need to be virtual in order to call it
from
a descendant using inherited. Calling inherited is simply the way for
descendants to take advantage of ancestor code and has nothing to do with
the purpose of virtual methods.
The purpose of virtual methods is polymorphism. Polymorphism is the
ability
to call a method of a class when you do not know the specific type of that
class, and the correct method will be called.
The classic (overused?) example:
TShape = class
x, y: integer;
procedure Paint; virtual; // paints a point
end;
TSquare = class(TShape)
len: integer;
procedure Paint; override; // paints a square frame
end;
TCircle = class(TShape)
radius: integer;
procedure Paint; override; // paints a circle frame
end;
TFilledSquare = class(TSquare)
color: TColor;
procedure Paint; override; // paints a square and fills it
// in this case only, Paint would likely call the ancestor's (TSquare)
Paint
end;
Without polymorphism, the only way I could paint each of the above shapes
is
to have a variable of the correct type. E.g. I could declare a variable of
type TShape, create an instance and call Paint, and it would correctly
paint
a point. But I could not use that same variable to paint a square, I would
have to have a separate variable of type TSquare to do that. Polymorphism
allows me to do this:
procedure PaintShape(shape: TShape);
begin
shape.Paint;
end;
procedure PaintAll;
var shape: TShape;
begin
shape := TShape.Create;
PaintShape(shape); // or just call shape.Paint here
shape := TSquare.Create;
PaintShape(shape); // or just call shape.Paint here
shape := TCircle.Create;
PaintShape(shape); // or just call shape.Paint here
shape := TFilledSquare.Create;
PaintShape(shape); // or just call shape.Paint here
end;
The point here is that I can pass any of these shape types to a method
that
only knows about TShape and none of the others, yet that method can call
Paint and the *correct* method will be called, not necessarily TShape's
Paint method.
That's what virtual makes possible - and what makes Delphi possible; why
it's is able to create instances and call methods of your descendant form
types even though the Delphi code that creates those forms knows nothing
about your descendants.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"It is error alone which needs the support of government. Truth can
stand by itself." - Thomas Jefferson
|
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
