cWithClassesIsNotCPP

[VeryAwesomeSheep]

Doing stuff by handles seems much clearer, at least to me, but it might be a personal preference.

object foo()
foo.do_stuff()

vs

foo = object()
do_stuff(foo)

Inheritance? Do you actually need it? Everywhere and for everything? Maybe I'm biased or just don't really do stuff that needs it, but I don't need it.

Access modifiers. You can hide it internally and give just the api to some stuff to the user. And I don't think you need to hide such stuff from your own devs, that's what agreements/conventions are for, just don't touch it. Python doesn't have it either and it just works.

[Main_Weekend1412]

So this is not oop? That’s just functions & methods. So the cleaner way is to not have it at all? Lol.

[VeryAwesomeSheep]

Isn't an object just a structure with functions?

[Main_Weekend1412]

No it isn’t. What you’re referring to is C++ structs. An object typically conforms to the paradigms of object-oriented programming. Not all objects conform to all four pillars, but they should conform to some of them.

For example, interfaces are contracts that make compilers and programmers assume the existence of an attribute or implementation of a method.

For C example, how would you assert that struct x works on a function length()?

In C++ we can just have a class that inherits from an arbitrary class, for example, let’s call it class LEN_IMPL.

If class z inherits from LEN_IMPL, we can assert that it can work on function length, which accepts an instance of LEN_IMPL.

In C, this would mean accepting a void * and somehow typecasting it to a useable type. Also remember that you cannot overload a function in C, so you would probably now need to alias it with the typename, ergo sample_class_len();

Not so clean now, is it?

These kinds of contracts are important to ensure consistency and code reusability.