On Thu, Aug 29, 2013 at 8:49 PM, Jerry Stuckle <jstuc...@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.
>> (To get the neurons connecting, think about early objective-C, when
>> the "object" stuff was done with a special purpose pre-processor.
>>
>> Shoot. Don't forget that C++ itself was once a pre-processor for C.)
>>
>
> That's like saying C is a preprocessor for assembler. Sure, the original
> C++ tools were preprocessors. However, they were preprocessors which
> provided the tools necessary to do OOP.
The originals were pretty primitive. The current state is somewhat
improved, but incomplete.
>> 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.
> 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, ...)
>> 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.
>> 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).
>> 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?
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
--
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/CAAr43iOH=MU8qBoE1LPGoMeYpeYBrJJ16nb66XtN2JOe__=w...@mail.gmail.com
