Values are opposed to objects because they have opposite properties, that is, values are not objects and objects are not values. For example, a value is immutable element which is passed by-copy (by-value) while objects are passed by-reference. In programming languages, values are normally stored in stack while objects are allocated in heap. Values are visible from and used by only this context while objects can be shared by many contexts. Values do not have a location in space (reference) while objects are characterized by a permanent reference.
Since OOP is about objects, values are not fully supported in this programming paradigm. In particular, the main purpose of classes in OOP consists in describing object types rather than value types. The only thing that is supported in most programming languages are primitive values with primitive types like integers. Another very important use of values supported in most OO languages is referencing. However, we are not able to create application-specific values and application-specific references -- they have a platform-specific format and behavior. (One exception is C++ where classes can be used for describing both values and objects.)
In the concept-oriented programming (COP), both values and objects are first class citizens with the same rights. It is not simply a decorative enhancement but the recognition of the importance of values. Values in COP can account for a great deal or even most the program complexity.
For modeling values and objects COP introduces a novel programming construct, called concept. Concept is defined as a couple of two classes: one reference class and one object class. Reference class describes values while object class describes objects. (We call it reference class because the main role of values is a reference.) What is really new here is that these two classes cannot be used separately, that is, reference class and object class is one whole. The change of paradigm is that programming is reduced to manipulating value-object couples. In this context, COP informally relates to OOP as complex numbers relate to real numbers in mathematics. If in OOP elements have only one constituent -- an object, then in COP an element has always two constituents -- one value and one object, which are informally analogous to two constituents of complex numbers (imaginary and real part).
The next change is that inclusion relation is used instead of classical inheritance. In OOP terms, this means that a base element (value-object couple) may have many extensions. If values are used as references, then it is a basis for describing application-specific hierarchical address spaces like conventional postal addresses. For example, assume that concept Street is included in concept City which in turn is included in Country. After that each element is represented by a reference consisting of three segments: country (high), city (middle), street (low). This complex reference is a value which represents a complex object. The main different from OOP is that one country (base) can be shared among many cities (extensions) which in turn can be shared among many streets. Elements in COP are living in a hierarchical space (described by concept inclusion hierarchy) while in OOP they are living in a flat space although their classes are hierarchically ordered.
CoP Article: Informal Introduction into the Concept-Oriented Programming
CoP forum: http://conceptoriented.org/forums/index.php
Comment feed for this post
Note that COP does not belong to OOP and I described only one (of many) their distinguishing feature rather than a dichotomy of OO programming languages. In particular, it is important to understand the symmetry (duality) between values and objects which is absent in OOP but very important in COP.
OOP doesn't specify whether objects are passed by value or reference. That's an artifact of the language, rather than the object model. You're obviously quite happy to push the idea that this distinguishes OOP and COP, but there are many OO languages that support passing objects by value or by reference.
It would be perfectly possible to reify references using structs in C#, in the same way that your concepts reify them in COP. Merging structs and classes into a single form would be a largely syntactic enhancement.
You also use inheritance to refer strictly to single hierarchical inheritance. This is to strict. There are many many different approaches to inheritance and not all of them emply a hiearchy. Some people would consider inclusion as a form of inheritance.
I'd be very interested to know what other features COP offers, because having skimmed a few of the papers linked to on this site I haven't noticed any game changers.
You may not consider COP to be a fork of OOP, but it adds no more or less than Subject-oriented programming, Context-oriented programming or Ambient-oriented programming etc. They all change certain things about OOP; add certain features etc. But they're all OOP at heart.
Maybe I'm missing something?
"OOP doesn't specify whether objects are passed by value or reference. That's an artifact of the language, rather than the object model."
Strictly speaking you are right, but it is because OOP does not make big difference between values and objects and, as a consequence, the way they are passed is already a minor issue which can be implemented in different ways in different languages.
"You're obviously quite happy to push the idea that this distinguishes OOP and COP, but there are many OO languages that support passing objects by value or by reference. "
In COP, values and objects are opposed and to say "an object is passed by-value" is non-sense. In COP, an object is defined to be passed only by-reference -- otherwise it is not an object.
"It would be perfectly possible to reify references using structs in C#, in the same way that your concepts reify them in COP. Merging structs and classes into a single form would be a largely syntactic enhancement."
If we talk about values and objects then you are right -- it is not very difficult. But the main concern in COP is how objects are represented and how they are accessed, i.e., COP is about references (which are values). In this case coupling structs and classes is not a syntactic sugar because it changes how a program is viewed, how it functions and how it is written.
"I'd be very interested to know what other features COP offers, because having skimmed a few of the papers linked to on this site I haven't noticed any game changers."
For example, a great deal of the program complexity is not in objects (in classes) -- some functions are concentrated in references which are active elements of the program (and modularize its cross-cutting concerns). Another example, we need an additional keyword 'sub' which is opposed to the conventional 'super'. The third change is that each concept has two methods which need to be coordinated. The third important feature is that there are two (dual) overriding strategy: base methods can override extensions and (as usual) extensions can override base methods.
"You also use inheritance to refer strictly to single hierarchical inheritance. This is to strict. There are many many different approaches to inheritance and not all of them emply a hiearchy. Some people would consider inclusion as a form of inheritance."
Inclusion turns into inheritance under certain simplifying conditions (as well as COP turns into OOP under these conditions). But the opposite is not true.
So you're moving something usually left to the language into the paradigm; that's reasonable, but you're not adding anything that wasn't there before.
"In COP, values and objects are opposed and to say "an object is passed by-value" is non-sense. In COP, an object is defined to be passed only by-reference -- otherwise it is not an object."
Now we're arguing about terminology – you can define object to mean whatever you want, it doesn't change the fact that many languages allow objects to be passed by value... meaning that you can implement concepts, as you call them.
And as far as I call tell, there's nothing stopping an OO language from providing inclusion in-place of standard hierarchical inheritance. (It's been a while but) I'm pretty sure Beta provided an inheritance mechanism with similar capabilities (as well as the ability to pass objects by value or reference).
I'm just not seeing the big deal here. It seems like all of the things you've described fit well into existing OOP. Which is why I describe COP as a fork – another false dichotomy.
Unfortunately, most contemporary OO languages do [b]not[/b] suppport passing objects by-value -- and that is absolutely correct from the point of view of the OO paradigm (I would also do so if I had to implement an OO language).
"And as far as I call tell, there's nothing stopping an OO language from providing inclusion in-place of standard hierarchical inheritance. (It's been a while but) I'm pretty sure Beta provided an inheritance mechanism with similar capabilities (as well as the ability to pass objects by value or reference)."
Here is a very short comparison of inheritance vs. inclusion:
Inheritance: all objects exist in one flat space; one base has one extension; all segments have one platform-specific reference (identity) provided by the compiler
Inclusion: all objects exist in a hierarchy (as a tree); one base has many extensions; all segments have their own application-specific references (identities) provided by the programmer
Beta provides reverse overriding strategy (where base methods override the methods of the extensions) via so called inner methods, which is a very important and underestimated feature. The same reverse overriding strategy exists in COP but is implemented differently via reference methods of concepts (one method has two definition: one in reference class and one in object class). So in Beta, objects still are normal objects living in one flat space without a hierarchy but with the addition of the mechanism of inner methods.
So I do not see how inheritance (even with the Beta inner methods) can be converted to inclusion.