Object Orientation Rigor

Object Orientation is not clearly defined. Object Orientation is something that people find useful, but it needs to be better defined with more precision and rigor. This page also contains criticisms about procedural terminology too.

Problem: class vs object confusion

Classes and objects, what are they? Are objects variables, while classes are the type definition of a variable? Is the variable the object, or is an object not a variable?

Or are classes and objects interchangeable words that mean different things to different people? This is a serious, serious, very serious issue that needs to be addressed.

Problem: instance of a class?

Is an instance of a class proper wording? Do classes have instances? are the instances the variables? Let's go back to basics and compare it to CeeLanguage structs.. When we define a struct in a CeeLanguage and then use that in our program to do something useful, we have a struct typedef (type definition), along with a struct variable. Is the struct variable, an instance of the struct typedef? If so, then in OOP, a class instance is a variable associated with the class typedef. On the other hand, could an "instance" mean a particular variable state.. i.e if a CAR object is blue, it can be later painted red. Is a red car object a different instance than the blue car object? Or can an instance have different properties? Is the instance the car, or the particular car? If it is a particular car and not just the car, this confuses matters and this must be addressed.

Aside: for languages that don't have type defs, the type def is actually inferred, or figured out by the program/interpreter, rather than declared explicitly by the human.

Problem: are classes just extended structs?

Classes are similar to structs, but classes have methods, whereas structs don't have methods. If classes were instead called "extended structs" would this help clarify what classes are? If so, one could think of classes as extended structure typedefs, and extended structure variables. The variable is the item that changes state in your program, whereas the typedef is a specification/layout of that structure.

Problem: tuples, structs, records, and objects/classes

Are tuples like structs? (yes). Are tuples like objects/classes? (yes). Are tuples like records? (yes). Are structs like records? (yes).

Why? Because they all are for data. Structs are for data, as are tuples, as are records, as are objects (or classes?).

Are classes storing data, or is it the object that stores data?

Problem: typedef vs type

Is "type definition" redundant? Some languages call it "typedef" while others call it "type". On the other hand, some languages don't even have "type" or "typedef", such as PHP which figures out your types for you (hiding important details from you).

Should "type definition" be shortened to "type"? How about "type specification", or again maybe just "type" is better. In the GoLanguage they seemed to call it "type" instead of "typedef".

Problem: method, vs procedure, vs function

A method is very similar to a procedure. A procedure or function that is attached to an object is like a method. Is the method attached to the class, or attached to the object? which is it? Should the word "method" even be used, or should we instead call them "procedures"? In the CeeLanguage they call procedures just "functions". A void function in Cee is exactly like a procedure, but instead of calling it procedure they still call it a void function. Yet GetProcAddress? (in the windows api) confuses the matter: why is it called GetProcAddress? and not GetFuncAddress??

Problem: namespace vs unit vs module vs package vs include file

In some languages they call them namespaces, and in others they call them units, or modules. Some languages have packages. The CeeLanguage has include files, which are a bit like modules, but not really. Modules are like objects because modules contain a grouping of data and procedures. Objects are like dynamic modules because you can create and free objects, whereas modules cannot be created and freed at runtime.