4 ms·

> In the above program, why isn't `counter` an object? > C in itself has no concept of an "object". You answered your own question. Without syntax to say "th

> In the above program, why isn't `counter` an object? > C in itself has no concept of an "object". You answered your own question. Without syntax to say "this is an object", you can take literally ANYTHING Turing-complete, mentally group data+functions and then claim "it looks like an object, therefore it is an object, why wouldn't it be an object". "Excel is OO", "Dwarf fortress is OO", "x86 assembly is OO", "pen and paper is OO". Well, if everything is OO then nothing is OO, you've made it into a meaningless concept. I suggest we stick to reality. The most basic requirement for a language to be OO is to have some explicit or implicit syntax for objects. That seems to reasonably partition languages into OO and non-OO. > 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." I'm arguing no such thing, and I never said such a thing. Would appreciate if you didn't put words in my mouth. I'll ask again. In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? Possible answers: 1. FILE 2. DIR 3. None of them 4. Both of them 5. They stop being objects 6. New objects are created, and those own F 7.Something else Pick one. I will then pick any other option and argue that, in my opinion, my chosen answer is the correct one. And then it's suddenly a matter of opinion rather than a matter of fact, you won't be able to prove I am wrong, just like I won't be able to prove I'm right. So much for imaginary objects. EDIT > In the above program, why isn't `counter` an object? To drive my point home, why is it an object? Just because you see an object? All I see is a struct containing 5 pointers. Oh, some are function pointers? What's the difference, it's still just a struct containing 5 pointers. You consider it an object, I don't consider it an object, and none of us is wrong. However, an instance of a C++ class containing members and methods is unambiguously an object because the syntax clearly bound them together. Plus, you can do OO things with this object, which further reinforces the idea that it is an object.

skissane 3y ago
> Without syntax to say "this is an object", How about this syntax? #include "oo.h" DEFINE_CLASS(Counter, int METHOD(Counter,getValue,NO_ARGS);, void METHOD(Counter,increment,NO_ARGS);, void METHOD(Counter,decrement,NO_ARGS);, void METHOD(Counter,multiplyThenAdd,(int multiplyBy, int add)); ); That's valid C, given appropriate preprocessor macro definitions. It is a bit ugly, due to the limitations of the C preprocessor. (Maybe someone else can do better than me.) If C had a more powerful preprocessor, but was otherwise unchanged, the syntax could be a lot nicer. The DEFINE_CLASS() macro expands to declare a function: Counter* newCounter(void); Why isn't the return value of that function an object? Here is the contents of "oo.h": #include "cloak.h" #define JOIN(...) JOIN_IMPL(__VA_ARGS__,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) #define JOIN_IMPL(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,_11,_12,_13,_14,_15,_16,_17,_18,_19,_20,_21,_22,_23,_24,_25,_26,_27,_28,_29,_30,_31,_32,_33,_34,_35,_36,_37,_38,_39,_40,_41,_42,_43,_44,_45,_46,_47,_48,_49,_50,_51,_52,_53,_54,_55,_56,_57,_58,_59,_60,_61,_62,_63,...) \ _1 _2 _3 _4 _5 _6 _7 _8 _9 _10 _11 _12 _13 _14 _15 _16 _17 _18 _19 _20 _21 _22 _23 _24 _25 _26 _27 _28 _29 _30 _31 _32 _33 _34 _35 _36 _37 _38 _39 _40 _41 _42 _43 _44 _45 _46 _47 _48 _49 _50 _51 _52 _53 _54 _55 _56 _57 _58 _59 _60 _61 _62 _63 #define DEFINE_CLASS(name,...) \ typedef struct name name; \ typedef struct name { \ void *_privateData; \ JOIN(__VA_ARGS__) \ void (*destroy)(name**); \ } name; \ name* new##name(void) #define METHOD(class,method,args) \ (*method)(class* COMMA_IF(IS_PAREN(args)) WHEN(IS_PAREN(args))(EXPAND(EXPAND args))) #define NO_ARGS Where cloak.h is https://github.com/pfultz2/Cloak/blob/master/cloak.h https://github.com/pfultz2/Cloak/blob/master/cloak.h The above macros are admitttedly very hairy. If C had a better preprocessor, but was otherwise unchanged, they could look a lot nicer. > I never said such a thing. Would appreciate if you didn't put words in my mouth. A normal part of dialogue is, "I'm going to repeat your point back to you in my own words, and you can either agree with my restating of it, or point out at which point I've misunderstood you". That's what I was doing. "Would appreciate if you didn't put words in my mouth" is unnecessary hostility. > In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? Take any language which you agree is "OO". Add one new feature (if it isn't already there): functions/methods which don't belong to any class/object. Now the function you are talking about is possible in that language. Did the language thereby suddenly cease to be OO when we added that feature? Most people would disagree with "Yes". But if "No", what is the actual difference between C and that language?
- Tomis02 3y ago
  > > In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? > Take any language which you agree is "OO". ... A normal part of dialogue is answering the other person's questions. I asked the same question point blank several times, and you keep refusing to answer. Once you answer the question, then we can discuss your hypothetical scenarios about other languages. I believe I stated my question quite clearly. > Why isn't the return value of that function an object? > C in itself has no concept of an "object". We already went over this.
  - skissane 3y ago
    > In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? Possible answers: 1. FILE 2. DIR 3. None of them 4. Both of them 5. They stop being objects 6. New objects are created, and those own F 7.Something else I don't think your question necessarily has an answer, but if I have to pick, I'd say (3). F is a classless method; FILE and DIR are classes; as a classless method, F cannot belong to any class, so it can't belong to FILE or DIR. If the function was F(FILE, const char*, DIR) then F might be a method of FILE instead, if the code base is following the "this is first argument" convention.
    - Tomis02 3y ago
      > I don't think your question necessarily has an answer, And why is that? Are objects and OOP not clearly defined? If you proclaim FILE and DIR to be classes, should it not be extremely clear what are their methods? That's the problem right there, as I said it repeatedly. In C++, objects can be identified unambiguously. Whereas in C, if you keep insisting it's OOP, the answer is whatever you want it to be. "FILE is an object, and I'll handwave away all inconvenient details that get in the way of my perception of FILE as an object". Sorry, I expect a higher level of rigour. > F is a classless method > FILE and DIR are classes > If the function was F(FILE, const char, DIR) then F might be a method of FILE instead, if the code base is following the "this is first argument" convention. The C standard library doesn't seem to follows such a convention. For example: > fread(void , size_t, size_t, FILE ); > fgets(char, int, FILE ); > fseek(FILE , long int, int); If FILE is a class, is fgets a method of this class? If fgets is a method of FILE, why is F in my example not a method of FILE too?

skissane 3y ago

> Without syntax to say "this is an object", How about this syntax? #include "oo.h" DEFINE_CLASS(Counter, int METHOD(Counter,getValue,NO_ARGS);, void METHOD(Counter,increment,NO_ARGS);, void METHOD(Counter,decrement,NO_ARGS);, void METHOD(Counter,multiplyThenAdd,(int multiplyBy, int add)); ); That's valid C, given appropriate preprocessor macro definitions. It is a bit ugly, due to the limitations of the C preprocessor. (Maybe someone else can do better than me.) If C had a more powerful preprocessor, but was otherwise unchanged, the syntax could be a lot nicer. The DEFINE_CLASS() macro expands to declare a function: Counter* newCounter(void); Why isn't the return value of that function an object? Here is the contents of "oo.h": #include "cloak.h" #define JOIN(...) JOIN_IMPL(__VA_ARGS__,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) #define JOIN_IMPL(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,_11,_12,_13,_14,_15,_16,_17,_18,_19,_20,_21,_22,_23,_24,_25,_26,_27,_28,_29,_30,_31,_32,_33,_34,_35,_36,_37,_38,_39,_40,_41,_42,_43,_44,_45,_46,_47,_48,_49,_50,_51,_52,_53,_54,_55,_56,_57,_58,_59,_60,_61,_62,_63,...) \ _1 _2 _3 _4 _5 _6 _7 _8 _9 _10 _11 _12 _13 _14 _15 _16 _17 _18 _19 _20 _21 _22 _23 _24 _25 _26 _27 _28 _29 _30 _31 _32 _33 _34 _35 _36 _37 _38 _39 _40 _41 _42 _43 _44 _45 _46 _47 _48 _49 _50 _51 _52 _53 _54 _55 _56 _57 _58 _59 _60 _61 _62 _63 #define DEFINE_CLASS(name,...) \ typedef struct name name; \ typedef struct name { \ void *_privateData; \ JOIN(__VA_ARGS__) \ void (*destroy)(name**); \ } name; \ name* new##name(void) #define METHOD(class,method,args) \ (*method)(class* COMMA_IF(IS_PAREN(args)) WHEN(IS_PAREN(args))(EXPAND(EXPAND args))) #define NO_ARGS Where cloak.h is https://github.com/pfultz2/Cloak/blob/master/cloak.h https://github.com/pfultz2/Cloak/blob/master/cloak.h The above macros are admitttedly very hairy. If C had a better preprocessor, but was otherwise unchanged, they could look a lot nicer. > I never said such a thing. Would appreciate if you didn't put words in my mouth. A normal part of dialogue is, "I'm going to repeat your point back to you in my own words, and you can either agree with my restating of it, or point out at which point I've misunderstood you". That's what I was doing. "Would appreciate if you didn't put words in my mouth" is unnecessary hostility. > In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? Take any language which you agree is "OO". Add one new feature (if it isn't already there): functions/methods which don't belong to any class/object. Now the function you are talking about is possible in that language. Did the language thereby suddenly cease to be OO when we added that feature? Most people would disagree with "Yes". But if "No", what is the actual difference between C and that language?

Tomis02 3y ago
> > In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? > Take any language which you agree is "OO". ... A normal part of dialogue is answering the other person's questions. I asked the same question point blank several times, and you keep refusing to answer. Once you answer the question, then we can discuss your hypothetical scenarios about other languages. I believe I stated my question quite clearly. > Why isn't the return value of that function an object? > C in itself has no concept of an "object". We already went over this.
- skissane 3y ago
  > In my concrete example, given that FILE and DIR were classified as objects, to which of the so-called objects does F(const char*, FILE, DIR) belong? Possible answers: 1. FILE 2. DIR 3. None of them 4. Both of them 5. They stop being objects 6. New objects are created, and those own F 7.Something else I don't think your question necessarily has an answer, but if I have to pick, I'd say (3). F is a classless method; FILE and DIR are classes; as a classless method, F cannot belong to any class, so it can't belong to FILE or DIR. If the function was F(FILE, const char*, DIR) then F might be a method of FILE instead, if the code base is following the "this is first argument" convention.
  - Tomis02 3y ago
    > I don't think your question necessarily has an answer, And why is that? Are objects and OOP not clearly defined? If you proclaim FILE and DIR to be classes, should it not be extremely clear what are their methods? That's the problem right there, as I said it repeatedly. In C++, objects can be identified unambiguously. Whereas in C, if you keep insisting it's OOP, the answer is whatever you want it to be. "FILE is an object, and I'll handwave away all inconvenient details that get in the way of my perception of FILE as an object". Sorry, I expect a higher level of rigour. > F is a classless method > FILE and DIR are classes > If the function was F(FILE, const char, DIR) then F might be a method of FILE instead, if the code base is following the "this is first argument" convention. The C standard library doesn't seem to follows such a convention. For example: > fread(void , size_t, size_t, FILE ); > fgets(char, int, FILE ); > fseek(FILE , long int, int); If FILE is a class, is fgets a method of this class? If fgets is a method of FILE, why is F in my example not a method of FILE too?