On 8/30/2013 10:44 AM, berenger.mo...@neutralite.org wrote:
Le 30.08.2013 15:11, Jerry Stuckle a écrit :
On 8/30/2013 2:00 AM, Joel Rees wrote:
Okay, so, for you, supporting inheritance and polymorphism at run-time
rather than at compile time is not sufficiently OOP.
And I don't particularly care about that distinction.
I'm fine with ending the discussion there.
--
Joel Rees
You keep claiming it can be done, but have done nothing to show how
it can be done. So all I can assume is you cannot support your
statement, because it can't be done.
Don't worry - I've heard similar statements over the years from
others who don't understand OOP. None of them have been able to
support their statements, either.
Jerry
Here is what you defined for inheritance and polymorphism:
============
3. Inheritance: the ability to extend an existing class, to provide
additional or different functionality via additional messages in the
derived class. Inheritance takes advantage of the similarities in the
base an derived classes. The base class has no knowledge of the derived
class and, in fact, may not even know it is being used as a base class.
Additional classes can be derived from the original base and derived
classes with no change to the existing code. This cannot be done in C.
4. Polymorphism: the ability to send messages to a derived class object
when you believe you have an object of the base class. This allows
functions to operate on any class in the derived hierarchy, while only
having to worry about the messages defined in the base class. This also
cannot be done in C.
============
Note that we agree on those definitions.
Now, can you explain why the link I provided does not meet those
requirements?
I agree the link emulates a kind of polymorphism in the limited case it
shows. However, it does not show inheritance (a basic requirement for
polymorphism), and quickly falls apart when you get into real-world code.
For instance, let's say you try to emulate inheritance in C. What
happens the derived class needs to call the base class member of the
same name? Sure, you can use the emulated vtable - but you have to know
what offset the base class is in the vtable. Say you have a case like this:
struct employee
struct manager
Now you need to add contractors. Rather than create a new class
hierarchy, you change your existing one to:
struct person
struct employee
struct manager
struct contractor
Now the entire vtable has changed - and if manager calls the function in
vtable[0], it will call the one in person, not employee.
Or, taking the second hierarchy again: say person has member xyz, but
employee doesn't. When manager calls xyz, it needs to know to call the
one in person, not employee. But later, you go back to change employee
to also have a member xyz. Now you have to change manager to call
employee's xyz instead of the one in person.
The result is a change in a base struct or the base struct hierarchy
results in changes to all of the derived struct - even though the base
struct public interface has not changed.
OO languages eliminate these problems by handling everything themselves.
In any of the above cases, all that needs to be done in C++ is
recompile the program(s). The compiler takes care of everything else.
For now, except saying to everyone that 1) they do not understand OOP
and 2) you teach it from 25 years, you never gave any example of things
we could do in any OOP language that we could not make in C according to
your definition of OOP (on which I agree, again) not you destroyed the
source code pointed by the link I gave.
I didn't comment on your example extensively because I thought you
understood the limitations. And these are just the start - I could
continue on.
Oh, and, you also said something which implied that I said that SDL is a
language, which is something I never said. Well, to be more precise, the
functions and structures I referred to where obviously owned by
libsdl1.2-dev (to write the Debian package's name) which is a library.
So, you avoided replying to real arguments with yours, and you even used
a straw man to discredit me?
Sorry if you think I implied SDL is a language. I meant no such thing.
But I don't see where SDL implements any form of OO programming.
I will refrain my envy of irony here, instead I will be direct: I have
seen people which were using a lot the argument of being older than me
to convince me that I was wrong. They never convinced reality, when what
they did failed, why my solutions were working fine. Wisdom and
knowledge are not only a matter of age and teaching. Including teachers.
This is the reason why I rarely accept an argument if it is not
correctly built: explanation + example, so that it can be countered or not.
One thing I have learned over the years. You cannot teach those who
will not learn.
While I am at it, let me say you that, a machine, in common language
(I'm not very good with mathematics), have internal states that you do
not need to know to use it's function. I have no idea about all the
states of my car when I am driving. For example, I do not know, or need
to know, the states of the spark plugs.
Sure, machines have states. And both peaches and quarries have pits.
But that doesn't mean they are the same thing.
Your car is not a program. And we are not talking math here. We are
talking programming. They are entirely different things.
Jerry
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5220d0a4.6000...@attglobal.net
