Re: What's the easiest and/or simplest part of Linux Kernel?
On 8/30/13, Jerry Stuckle <jstuckle@attglobal.net> wrote:
> On 8/29/2013 8:25 PM, Joel Rees wrote:
>> On Thu, Aug 29, 2013 at 8:49 PM, Jerry Stuckle <jstuckle@attglobal.net>
>> wrote:
>>> On 8/29/2013 12:45 AM, Joel Rees wrote:
>>>> (I really don't have time to do this.)
>>>>
>>>> On Thu, Aug 29, 2013 at 12:17 PM,
>>>>> [Somebody replied to somebody, arguing that C can't do objects.]
>>>>
>>>> The syntax does become obtuse, unfun, cluttered, etc., but it can be
>>>> done.
>>>
>>> I didn't say C can't do objects. I said it can't do Object Oriented
>>> Programming. Two entirely different things.
>>
>> End of argument, if you could just see what you just said.
>
> Yep, because you obviously don't understand the difference between
> objects and object oriented programming.
>>>> Admittedly, the "object" syntax becomes a separate syntax and language
>>>> from the C part when you do OOP in unadorned C. You have to leave the
>>>> basic operators (+-*/%, etc.) out of the object-oriented language and
>>>> syntax. (Which is part of the reason it becomes unfun.)
>>>>
>>>
>>> Please show how you can do inheritance and polymorphism in C.
>>
>> You do understand that "in C" can be read two or three ways.
>>
>> But do you understand that not everyone agrees that the assertion of
>> "within the unadorned syntax of C" is the important one?
>>
>> Not going as far as writing the compilers (or the
>> compilers-by-pre-processing) in C, there is still a way of using
>> unadorned C to induce a metalanguage of objects on C.
>>
>
> Again, please show how you can do inheritance and polymorphism in C.
>
>>> And why do
>>> you need to leave the basic operators out? They are inherent to both
>>> languages.
>>
>> I'm not talking about using an unadorned C compiler to compile either
>> C++ or objective-C.
>>
>> I'm talking about programming OOP in C. The OOP operators might look like
>> this:
>>
>> obj1->plus( obj2->neg() );
>>
>> plus() and neg() would be the operators, and the OOP language is
>> projected onto C function call syntax.
>>
>> If you have complaints about calling methods operators, do you
>> understand Lisp? (or FORTH, ...)
>>
>
> Then show how to do inheritance and polymorphism in C. And yes, I did
> FORTH in the early 80's and Lisp a bit later. Haven't used either for
> years, though.
>
>>>> You have to use #include skillfully, and you have to explicitly put
>>>> function pointers in structures. It kind of turns things upside down,
>>>> a bit, and a little inside-out. It'll make even seasoned C programmers
>>>> seasick. And the syntax is not as flexible as C++.
>>>
>>> Again, please show how to do inheritance and polymorphism in C.
>>
>> If you understand what I mean by using function pointers in
>> structures, you should be able to see that inheritance and
>> polymorphism are simply matters of providing certain functionality in
>> support libraries, and adding appropriate pointers in the structures
>> that define the objects.
>>
>
> Then you should easily be able to show how to do inheritance and
> polymorphism in C.
>
>>>> Which is all why C++ was written as a separate language.
>>>>
>>>> But it can be done.
>>>
>>> Once again, please show how to do inheritance and polymorphism in C.
>>
>> You're going to have to intuit the libraries that I am implicitly
>> inferring have been written and are being linked in, appropriate
>> headers being included, etc., and not even trying to provide any
>> syntactic sugar:
>>
>> ----------------------------
>> struct my_object_s
>> {
>> pfii_f constructor, destructor;
>> pfiv_o inherited_context, local_context; /* local_context is for
>> polymorphism. */
>> pfam_f method1;
>> pfam_f method2;
>> ...
>> } my_object_o;
>> ---------------------
>>
>> I assume you will complain that I'm just talking about providing the
>> functionality without the syntax of objects, and you'd be sort of
>> right. And you should complain that the convention of ending method
>> type declarations with "_f" and object type declarations with "_o" is
>> unenforceable (and ask whether the convention is anywhere explicitly
>> documented).
>
> That is neither inheritance nor is it polymorphism. It is simply a set
> of pointers to functions within a structure.
I am not a C programmer (just Java), but do you say that you are _not_
splitting hairs here?
A quick google search gives:
http://www.codeproject.com/Articles/10900/Polymorphism-in-C
http://www.codeproject.com/Articles/108830/Inheritance-and-Polymorphism-in-C
Yes clunky, yes not "fun", yes not "supported with inbuilt syntax",
but wasn't that Joel's point all along?
>>>> By the way, mathematically speaking, objects are machines.
>>>
>>> Maybe mathematically speaking, but we're talking programming here.
>>
>> Is programming somehow independent of mathematics?
>>
>>> In
>>> programming, variables have state. Functions have behavior. Objects
>>> have
>>> both state and behavior.
>>
>> And that is different from mathematical automata how?
>>
>
> In programming, objects are not machines. About the only "machine"
> concept I can think of is the old "state machine" from the 70's.
>
>> OOP is a paradigm, a set of rules for projecting certain aspects of
>> automata onto existing programming tools. The paradigm has a lot of
>> implicit rules that are not well documented. If you understand the OOP
>> class of paradigms, you may use the tools effectively. Or not
>> effectively. Or not at all.
>>
>> I think I understand the paradigms, but I find myself feeling like I'm
>> in a straitjacket when trying to use them. Most of the programs I
>> write do not project well onto the OOP paradigm. I suppose that may
>> have something to do with being spoiled by an early introduction to
>> assembler and FORTH, and with learning C at the same time as I was
>> learning m4 and lisp.
>>
>>>> None of which has anything to do with the simplest part of the Linux
>>>> kernel for a C newbie to try to drown in.
>>
>> --
>> Joel Rees
>>
>>
>
> No, OOP is quite well documented. I understand them well - been doing
> (and teaching to corporate programmers) OOP for over 25 years now.
>
> For your education - OOP consists of four basic principles:
>
> 1. Encapsulation: making internal variables (states) and possibly some
> messages unavailable to the external world. In C++, this is done with
> the "private" keyword; "protected" is an extension to the OO paradigm.
> This part can be emulated in C, but it's awkward.
>
> 2. Message passing: Telling the object to perform some action
> (behavior). In C++ this is done mostly with member functions; however
> due to language restrictions the language also includes "friend"
> functions. This can also be emulated in C, but is awkward.
>
> 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.
>
> As I said - you can emulate Object Based programming in C, although it
> is messy. You cannot create Object Oriented programs in C.
Are you saying you can NOT emulate inheritance in C?
Are you saying you can NOT emulate polymorphism in C?
Again, albeit with clunkyness, syntactic ugliness,
non-compiler-enforcement but only "policy" enforcement of visibility
constraints etc etc?
So again, are you saying that you are not merely splitting hairs over
terminology here?
If so, can you please explain why not, in terms that a non-C
programmer can understand?
Thank you
Zenaan
Reply to: