Andrew Solomon wrote:
On Thu, Aug 3, 2017 at 8:48 PM, hw <[email protected] <mailto:[email protected]>> wrote:
Andrew Solomon wrote:
My instinct before trying this would be to move the methods which FOO
needs back into FOO (removing them from BAR).
Is there a reason this won't work for you?
Hmm. I haven´t thought of that because they don´t belong into FOO.
They also won´t work in FOO because both FOO and BAR know about the object
they represent via what you could call a handle. This handle is very much
like an index of a row in a table in a database. The handle BAR knows can
be used with objects represented by BAR, and the handle FOO knows can be
used with objects represented by FOO. Though these handles are identical,
their content differs. You can do things with BAR-objects you can´t
do with FOO-objects and vice versa. FOO and BAR are partly the same,
partly different, that´s why there´s a class for each of them and why
BAR is descended from FOO.
If I moved the methods from BAR into FOO, they would use the handle of FOO
instead of the handle of BAR. All the methods in FOO would need a way to
somehow figure out whether they can be used in the current context (i. e.
what type of object the class has been instantiated for) or not.
I think the simplest approach would be to give both FOO and BAR a "handle"
method so that the user of the handle doesn't care which one it is.
It would even be possible to let the instance figure out whether it is an
instance
of a FOO or of a BAR. --- The tricky thing in this case is that a BAR literally
*is* a FOO from one perspective while it is not a FOO from another perspective.
Both perspectives are valid and required for the whole to function. --- Still
every
method of the class would have to check for what type of object the class was
instantiated for because not all methods of the class would be applicable to all
types of objects. Hence I made two classes, and hece BAR descends from FOO.
I think letting each instance figure out what type of object is would be a very
bad design: confusing for me as the programmer, confusing for everyone else who
might look at it, confusing for any program that uses the class, and thus overly
prone to errors and breakage.
The huge advantage of OOP is that I can wield about and combine the objects in
whatever way I see fit, without breaking or forgetting anything and without
doing
anything wrong because the objects take care of themselves. That allows the
programs doing something with the objects to concentrate on what they need to do
instead of having to (re-)implement methods for doing something every time along
with the implementation for doing something.
It "only" requires the objects and their methods to be implemented safe, sound
and
sane. Making an object with which it isn´t clear what it actually is and what
it
is capable of seems anything but safe, sound or sane.
I could add an object type so that the instances can know what type of
object they represent, and BAR would then become obsolete because I could as
well move all methods from BAR into FOO, defeating the point of OOP.
On Thu, Aug 3, 2017 at 7:44 PM, hw <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Hi,
suppose I have a class FOO and a class BAR. The parent of BAR is
FOO.
I would like FOO to /use/ BAR because BAR has some methods needed
by FOO.
BAR is /decended/ from FOO because FOO has many methods needed by
BAR.
Is this possible, or does it lead to some endless recursion when
compiling?
--
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
For additional commands, e-mail: [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
http://learn.perl.org/
--
Andrew Solomon
Mentor@Geekuni http://geekuni.com/
http://www.linkedin.com/in/asolomon
<http://www.linkedin.com/in/asolomon>
--
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
http://learn.perl.org/
--
Andrew Solomon
Mentor@Geekuni http://geekuni.com/
http://www.linkedin.com/in/asolomon
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
http://learn.perl.org/
