I looked around l.d.o/debian-user, but cannot find an admin address
(sorry, I bit stupid sometimes).
Can anyone tell me where my email went - see below - ??
TIA
Zenaan
---------- Forwarded message ----------
From: Zenaan Harkness <z...@freedbms.net>
Date: Sat, 31 Aug 2013 12:56:13 +1000
Subject: Re: What's the easiest and/or simplest part of Linux Kernel?
To: debian-user@lists.debian.org
On 8/31/13, Jerry Stuckle <jstuc...@attglobal.net> wrote:
> 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.
So you are saying that for this "fake OO" to be "true fake OO":
it would have had to provide for:
- a change to the "interface" of employee, namely overriding part of
person's interface
- which interface is used by manager
- with no source code changes to manager
- with only a recompile required to result in manager now using the
new implementation of person's interface ('part thereof') which
implementation has been "added to" employee's implementation
Is this a fair statement of the problem?
Surely this statement of the problem, leads to its own solution (as
far as this Java programmer can see) for a "true" fake OO
implementation:
Use double-indirection, ie two vtables,
one for the "interface",
which contains pointers to the pointers in the implementation vtable.
So each child class just overrides any/all of the implementation, by
customizing its own implementation interface vtable.
A bit convoluted, but that's why you'd probably use a C++ compiler of course.
>> 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.
Please do. I am just not understanding how "true fake OO cannot be
done in C". And I am not a C programmer, so I assume I am missing
something obvious.
>> 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.
Now now. Let's keep it technical please. I am personally genuinely
interested in understanding this problem (of implementing "true fake
OO" in C).
Thank you for your patience
Zenaan
--
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/caosgnsr8d_nc9hykk-slzzamcoz8wawxcgtfwmzs5bocoap...@mail.gmail.com
