I see the definition of 'instances' and it makes sense when dealing with types that define physical objects, so any cat is an instance of the type 'cat', however, why do we discuss 'instances' of numbers, or computer programs? What would the 'instances' of these be, or in the case of a number should it be 'occurence'? It seems most 'instances' are tokens but how about for purely abstract ideas?

In the language of multi-sets {2,2} is described as having multiple 'instances' of the number two, however should 'occurrence' be a more valid term due to the abstract nature?

  • a is an instance of the unary predicate P iff the proposition P(a) is true, regardless of whether P is "abstract". Thoughts aren't numbers, numbers aren't tuples, pairs aren't 2 etc.
    – J.G.
    Nov 6, 2022 at 13:44
  • How about 'instances' of tropes, which is where I think this language comes from?
    – Confused
    Nov 6, 2022 at 14:07
  • They can be instances of "number".
    – J.G.
    Nov 6, 2022 at 14:09
  • @J.G. yes, you are correct, we could say that these are all occurences, except perhaps if we see '2' as being defined entirely by real quantities and we could see any '2 things' as an instance satisfying a predicate?
    – Confused
    Nov 6, 2022 at 14:11
  • 2
    Take the dialectic counterpart: an instance is a case of a class. In general, a class is general, abstract, an instance is particular, concrete.
    – RodolfoAP
    Nov 7, 2022 at 19:05

2 Answers 2


In programming types and classes are abstract structures that define how a chunk of data is to be interpreted or what information it entails and how other structures can interact with it.

Types (in programming) would be more of a "how to read it" for example 1001 could be read as a the binary number 9 but it could also be read as -1 if you take the first bit a -sign or -7 if you use 2s complement and if you use the number as an index for a lookup table lots more interpretations are possible. So same data different interpretation, that's where you create clarity by setting a type which indicates how to read something.

Classes on the other hand could also chunk heterogeneous data pushing it in some form of "object" that could have a state, functionality and properties. Behind the scenes it's still just data but it's encapsulated and grouped together and so other parts of the program could treat it as an entity and pass the entire thing around rather than just it's parts.

Now classes themselves would be blueprints on how to construct these objects while the object itself would be called an "instance" of a class. And the process of creating objects using a class would be called instantiating.

So the class/type would be an abstract definition while the object or variable of that type would be a concrete representation.

Now depending on the language this "created by a class" is handled more strict or loose. Some would only consider an object produced by the class to be an instance of the class while others "duck type" (that is if it walks like a duck, quacks like a duck, ... it's likely a duck). So in the first case only an object produced by the initialization rites of the class would be an instance of the class, while in the second case anything that behaves like and object instantiated by the class would be an instance of the class or rather a different part of the program using that chunk of data could be instructed to "read this as if it were X".

And similarly you can define numbers in that way and group them or form hierarchies. For example you could define numbers as elements that support the +-*/ operations then go on to define real numbers which are a subset of numbers so an instance of real numbers would also be an instance of numbers.

  • The idea of 'type' makes sense to me, however it is realized, but when people start talking about sets, I tune out. A database is how things are stored, and I can do a lot with SQL while ignoring the theory of sets entirely. Same as riding a bike or throwing a ball without (or in spite of) knowing any physics.
    – Scott Rowe
    Dec 27, 2022 at 14:14

A concept is a die. What it cast is an instance.

"Number" is a concept / class / type. "47" is an instance of it.

If someone ask you to think of a number or choose a jacket in a jacket shop he is giving you a concept and a concept alone. You go fit a "concrete" object in that concept.

Note that there can be a hierarchy of concepts with only the leaves as objects.

You think in concepts. You work in objects.

In programming the whole designing phase is playing with concepts. A database table, a class, a function etc in your head is a concept. When you go in implementation phase you realize those concepts by writing code. Now you have instances / objects.

As I said above there can be a hierarchy. You make just one table and never it copies. You make copies of a class, those are instances, they are in memory, you can put data in them. You cannot put data in classes.

So, an object in OOP sense itself is a container, a concept, and data it contain is the leaf, the thing you manipulate, change and move around.

At another level of abstraction (conceptualization) objects are instances, copies of classes or whats cast by classes (dies).

The classes themselves are physical stuff casted by the die in your head which you know as concept of that class.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .