Let's ignore any particular language specification. Focusing too much on the specifics of a particular language can prevent you from seeing the big picture - in this article, we're not concerned with the details of any particular implementation. Let's think about ideal circumstances.
By the way, these are my personal methodologies and ways of thinking - they are no more correct than my opinion about vanilla bean ice cream. You either like my way of thinking, or you don't, and either way is fine.
A class tells you what information means, what you can do with it, and how you can do it. I've heard some people refer to classes as concepts, but I'll tackle those in a moment.
Yep. That's it. Ones and zeros.
Here's where things get interesting. An object has no meaning. A class has no substance. But an instance? It is the combined application of the two, having both meaning and substance. The object holds the information, and the class dictates the treatment.
How does a class dictate the treatment? Well, to start, someone intelligent has to design the class so that it serves a purpose. Therefore the designer, though the class, dictates the treatment of the underlying information. Classes just proxy the intentions of their creators. It is up to the creator to properly express their intentions in their language of choice.
Concepts are like meta-classes - they serve as guide rails for the design of classes, making sure that many classes mesh together nicely in generic programming. A class can implement, or support, a concept if it meets the requirements of the concept. Concepts can be checked and enforced by the language, or they can be written in some design document somewhere with the project files. Either way, classes are not concepts.
Despite what some may tell you, methods are not an integral part of a class. Primitive types, by my definitions above, are classes. An overwhelming majority of people you talk to will tell you that primitives don't have methods. They totally could, if the language said so, but most languages don't. Why? Because they don't need to.
Yes, there are operators, but most people will agree with me that a method is 'part of the class'. If it's not 'in the class', it's a function. Operators are just functions. Methods are just syntactic sugar for functions - they are a shortcut syntax invented by the language to more closely model a specific way of thinking.
The only line between functions and instances/objects is language specifications. "Functor" is a fun term invented as a result of the imaginary line that languages have drawn between two of the same thing.
Functions act on instances, not objects - they need to know how to treat the objects, and classes provide that knowledge. Functions are instances too, meaning that functions can act on (or with) other functions.
Perhaps the most startling thing to realize is that classes are just big functions spread over a wide area. Classes (inter)act on (with) other classes to accomplish a goal. Just as a function doesn't have to end, class interactions don't have to either either. (Think games)
Integers and reals are different types, but in memory they're generally about the same number of bytes. The distinction between them is one we create with our minds: we treat them differently. Primitive types are classes, whether you like it or not.
It's a bit.