[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: What's the easiest and/or simplest part of Linux Kernel?
From:       Jerry Stuckle <jstuckle () attglobal ! net>
Date:       2013-08-30 17:04:36
Message-ID: 5220D0A4.6000306 () attglobal ! net
[Download RAW message or body]

On 8/30/2013 10:44 AM, berenger.morel@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-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/5220D0A4.6000306@attglobal.net

[prev in list] [next in list] [prev in thread] [next in thread]