4 ms·

> It isn’t a thing in a C++ But it is a thing in OOP. That's the point. C++ is multiparadigm. All the OOP gurus will tell you that objects shouldn't expose the

> It isn’t a thing in a C++ But it is a thing in OOP. That's the point. C++ is multiparadigm. All the OOP gurus will tell you that objects shouldn't expose their internal data, only methods. That's why the so-called encapsulation is constantly brought up. People telling you C is OOP will say "FILE is an object, the FILE struct + fopen/fclose/fwrite constitute an object, FILE is opaque, we can only interact with its internals through the public methods". "DIR is an object, ...". And so on. And the problem is that when the Linux C API exposes a function that takes both a FILE and a DIR, and operates on both their internals, your whole idea of OOP-ness shatters because a method can only belong to a single object, by definition.

skissane 3y ago
> And the problem is that when the Linux C API exposes a function that takes both a FILE and a DIR, and operates on both their internals, your whole idea of OOP-ness shatters because a method can only belong to a single object, by definition. You can do the same in Smalltalk though-create a utility class containing a method which operates on one instance of each class, and create accessors to expose all their internals. If the ability to do that means C isn’t an OO language, then Smalltalk isn’t an OO language either. And if Smalltalk isn’t an OO language, then OO languages don’t exist.
- Tomis02 3y ago
  I'm confused by the sudden digression to Smalltalk. I was talking about C. I'll restate my point. Take the GNU C library. You don't own it, you just use it. It exposes some types (FILE, DIR), and some functions that use these types. Then, some people look at this API and proclaim that FILE and DIR are (conceptually) objects, and that there's no difference to having 2 C++ classes, it's just syntactic sugar. And that, therefore, C is OOP (or at least the design of libc). So now I ask - to which of the so-called objects does F(const char, FILE, DIR) belong? The answer is whatever you want it to be, because they're only objects in your mind, and you can imagine that F belongs to FILE, or to const char, or to all of them, or FILE/DIR stop being objects, and so on. Without syntax for objects (either explicit or implicit by convention), it's up to your imagination to decide what are the objects in your program. But if imagination is the criteria for OO-ness, then any programming language can be declared OO. OO is such a fuzzy concept that almost every feature and "pillar" is optional except objects. My point is that if a language doesn't have a syntax for objects then it's not actually OO. You can, of course, apply an OO mindset to your C program, but you can apply an OO mindset to anything Turing-complete, from Haskell to SQL and x86 assembly, so that's not saying much. If you approach everything with an OO mindset, that doesn't mean everything is OO. Syntax is real, mindset is just in your mind.
  - skissane 3y ago
    > I'm confused by the sudden digression to Smalltalk. I was talking about C. I'll restate my point. You are arguing "C cannot be an OO language because it lets you do X, and an OO language won't let you do X." My counterargument is "Smalltalk lets you do X, but everyone agrees that Smalltalk is an OO language; hence, you claim that if a language lets you do X it can't be an OO language must be false". > So now I ask - to which of the so-called objects does F(const char, FILE, DIR) belong? The answer is whatever you want it to be, because they're only objects in your mind, and you can imagine that F belongs to FILE, or to const char, or to all of them, or FILE/DIR stop being objects, and so on. If a language permits methods/functions which do not belong to any class, does that mean it can't be OO? A class-less method/function is equivalent to a single-method utility class. A language can't be OO if it lets you create a utility class? > Without syntax for objects (either explicit or implicit by convention), it's up to your imagination to decide what are the objects in your program. Consider this C code: // Declarations in counter.h typedef struct { void *privateData; int (*getValue)(Counter*); void (*increment)(Counter*); void (*decrement)(Counter*); void (*destroy)(Counter**); } Counter; Counter* newCounter(); // In main function: Counter* counter = newCounter(); printf("Initial value: %d\n", counter->getValue(counter)); counter->increment(counter); printf("After increment: %d\n", counter->getValue(counter)); counter->decrement(counter); printf("After decrement: %d\n", counter->getValue(counter)); counter->destroy(&counter); assert(counter == NULL); In the above program, why isn't `counter` an object? Assumably "privateData" is just a pointer to an int, but for all you know, the Counter value is actually stored as EBCDIC Roman numerals. > My point is that if a language doesn't have a syntax for objects then it's not actually OO. C in itself has no concept of an "object". But, there are certain conventions you can adopt in C code which make something an "object". My code above is one example of such a convention, there are others – for example, Microsoft COM (an object is a struct whose first member is a pointer to a struct of function pointers, and the remainder of the struct is private to the implementing class).
    - gyrovorbis 3y ago
      ^ This, 100%. GTk's GObject type system which powers the entire GNOME stack is a similar object-oriented C type system with a virtual table pointer as the first member of an object, similar to Microsoft COM and C++. The entire Objective-C runtime which is what powers the OO core of the language was also written with a similar purely C type system... It's just a small compiler layer on top...

skissane 3y ago

> And the problem is that when the Linux C API exposes a function that takes both a FILE and a DIR, and operates on both their internals, your whole idea of OOP-ness shatters because a method can only belong to a single object, by definition. You can do the same in Smalltalk though-create a utility class containing a method which operates on one instance of each class, and create accessors to expose all their internals. If the ability to do that means C isn’t an OO language, then Smalltalk isn’t an OO language either. And if Smalltalk isn’t an OO language, then OO languages don’t exist.

Tomis02 3y ago
I'm confused by the sudden digression to Smalltalk. I was talking about C. I'll restate my point. Take the GNU C library. You don't own it, you just use it. It exposes some types (FILE, DIR), and some functions that use these types. Then, some people look at this API and proclaim that FILE and DIR are (conceptually) objects, and that there's no difference to having 2 C++ classes, it's just syntactic sugar. And that, therefore, C is OOP (or at least the design of libc). So now I ask - to which of the so-called objects does F(const char, FILE, DIR) belong? The answer is whatever you want it to be, because they're only objects in your mind, and you can imagine that F belongs to FILE, or to const char, or to all of them, or FILE/DIR stop being objects, and so on. Without syntax for objects (either explicit or implicit by convention), it's up to your imagination to decide what are the objects in your program. But if imagination is the criteria for OO-ness, then any programming language can be declared OO. OO is such a fuzzy concept that almost every feature and "pillar" is optional except objects. My point is that if a language doesn't have a syntax for objects then it's not actually OO. You can, of course, apply an OO mindset to your C program, but you can apply an OO mindset to anything Turing-complete, from Haskell to SQL and x86 assembly, so that's not saying much. If you approach everything with an OO mindset, that doesn't mean everything is OO. Syntax is real, mindset is just in your mind.
- skissane 3y ago
  > I'm confused by the sudden digression to Smalltalk. I was talking about C. I'll restate my point. You are arguing "C cannot be an OO language because it lets you do X, and an OO language won't let you do X." My counterargument is "Smalltalk lets you do X, but everyone agrees that Smalltalk is an OO language; hence, you claim that if a language lets you do X it can't be an OO language must be false". > So now I ask - to which of the so-called objects does F(const char, FILE, DIR) belong? The answer is whatever you want it to be, because they're only objects in your mind, and you can imagine that F belongs to FILE, or to const char, or to all of them, or FILE/DIR stop being objects, and so on. If a language permits methods/functions which do not belong to any class, does that mean it can't be OO? A class-less method/function is equivalent to a single-method utility class. A language can't be OO if it lets you create a utility class? > Without syntax for objects (either explicit or implicit by convention), it's up to your imagination to decide what are the objects in your program. Consider this C code: // Declarations in counter.h typedef struct { void *privateData; int (*getValue)(Counter*); void (*increment)(Counter*); void (*decrement)(Counter*); void (*destroy)(Counter**); } Counter; Counter* newCounter(); // In main function: Counter* counter = newCounter(); printf("Initial value: %d\n", counter->getValue(counter)); counter->increment(counter); printf("After increment: %d\n", counter->getValue(counter)); counter->decrement(counter); printf("After decrement: %d\n", counter->getValue(counter)); counter->destroy(&counter); assert(counter == NULL); In the above program, why isn't `counter` an object? Assumably "privateData" is just a pointer to an int, but for all you know, the Counter value is actually stored as EBCDIC Roman numerals. > My point is that if a language doesn't have a syntax for objects then it's not actually OO. C in itself has no concept of an "object". But, there are certain conventions you can adopt in C code which make something an "object". My code above is one example of such a convention, there are others – for example, Microsoft COM (an object is a struct whose first member is a pointer to a struct of function pointers, and the remainder of the struct is private to the implementing class).
  - gyrovorbis 3y ago
    ^ This, 100%. GTk's GObject type system which powers the entire GNOME stack is a similar object-oriented C type system with a virtual table pointer as the first member of an object, similar to Microsoft COM and C++. The entire Objective-C runtime which is what powers the OO core of the language was also written with a similar purely C type system... It's just a small compiler layer on top...