[D-community-offtopic] Offlist reply ? - Fwd: What's the easiest and/or simplest part of Linux Kernel?

[Zenaan Harkness]

On 10/28/13, Jerry Stuckle <jstuckle at attglobal.net> wrote:
> On 10/27/2013 7:39 PM, Zenaan Harkness wrote:
>> Hi Jerry, I haven't done much programming for many years, and it seems
>> that on-list is no longer the place for this thread.
>>
>> I am personally still interested though, so if you would be so kind as
>> to send me any sort of brief off-list reply to the below email (on
>> something of a technical level), that would be really appreciated by
>> me.
>>
>> I am hoping to discover something I cannot see yet, as your certainty
>> on this topic implies I am indeed failing to see something.
>>
>> Thanks for your patience Jerry,
>> Zenaan

> Zenaan,
>
> Sorry, I don't do off-list conversations.  I learned a long time ago
> that trying to do things off-list rapidly expands and takes a huge
> amount of time.  And since to a consultant, time is money, I made a rule
> not to do any of it.

Sounds entirely reasonable :)
I can't not accept that...

> So, the only email help I provide nowadays is for my paying clients, and
> they pay for it.
>
> Again, sorry
> Jerry

OK no worries, then will you please respond on-list?

Personally I don't care at all re off-list or on-list - it's only
others who seem to care so much that they avidly read
emails they'd (apparently) rather not read :)
I do find that quite humorous.

Notwithstanding, you gave technical replies to Miles and the
others, so I was hoping for at least some (brief) answer to my
email suggesting "double-indirection pointer tables to
emulate polymorphism in C".

If you simply don't have time, I understand.

If you can spare a minute on-list, that will be really
appreciated by me - I'll copy the email below.

Again, I'm neither a C nor C++ programmer, merely a Java
programmer who would like to understand something that
it looks like I'm just not getting properly.

Here's the email I sent to debian-user (which gmail
appears to have messed up originally so that it never
made it to debian-user):

On 8/31/13, Jerry Stuckle <jstuckle at attglobal.net> wrote:
> On 8/30/2013 10:44 AM, berenger.morel at 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.
>>>
>>> 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