On 10/28/13, Jerry Stuckle <[email protected]> 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 <[email protected]> wrote: > On 8/30/2013 10:44 AM, [email protected] 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 _______________________________________________ D-community-offtopic mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/d-community-offtopic
