Concept Oriented Programming

Informal Introduction into the ConceptOriented Programming: http://conceptoriented.org/papers/CopInformalIntroduction.html

Contents of this page is NOT at all related to DDJ "Using networks for software development and distribution" article in June 01, 1999, saying "Concept-oriented programming makes it possible to write software that requires far less bandwidth to deliver, and thereby to increase apparent delivery speeds significantly. It also creates a mechanism for disseminating reusable code throughout the Internet."

DDJ Article: http://www.ddj.com/184410968

The ConceptOriented pages seem to be a "WalledGarden" on this Wiki. While 'ConceptOrientedProgramming' is used on pages outside the ConceptOriented WalledGarden, it's quite possible that they refer to the DDJ concept, not AlexandrSavinov's concept

If ObjectOrientedProgramming focuses on objects then CoP focuses on references or, more precisely, on reference-object pairs. In other words, any thing in the concept-oriented paradigm is viewed as consisting of two parts, called reference-object in CoP and identity-entity in ConceptOrientedModel. For example, let us consider the following instruction:

  button.click();

In OOP there is one button object represented by a native or direct reference stored in the variable. It is important that all references in OOP have one and the same standard format and provide direct access to objects without any possibility to customize their structure and/or behaviour.

In contrast, CoP models both references and objects so variables contain arbitrary references with the structure and functions defined by the programmer. Thus variable 'button' in the above example may store any data and method 'click' is actually intercepted by the reference before it can reach the object. For example, this button might be identified by name or by integer id. Notice that when a method is applied to a custom reference, the object native (direct) reference is not known and actually the object may reside anywhere in the world. So one of the main tasks of any reference consists in providing access to the represented object. On the other hand, the programmer still manipulates objects as if they were represented by direct native references (in the same way as in OOP) so we have the illusion of instant action.

To model references and objects CoP uses concepts (ConceptInCop) which generalize conventional classes. For example, instead of class Button we should define concept Button as follows:

  concept Button 
reference { // Reference class 
  int id; 
  ...
} 
object { // Concept class 
  String title; 
  ...
}

Notice that the concept consists of two parts: one reference class and one object class. Thus if we have a variable of this concept then it will store an instance of the reference class while an instance of the location of the object (an instance of the object class) is unknown -- it can be on disk, on another computer, on CD or on Mars. It is important that instances of the reference class are passed-by-value while instances of the object class are passed-by-reference.

Each concept has a parent concept specified by means of inclusion relation, i.e., any concept is included into a parent or base concept. Concept inclusion relation generalizes class inheritance. For example, concept Button could be included into concept Panel:

concept Button in Panel ...

Why included and not inherited or ''extends'’? Because the base concept plays a role of outside space, environment or context for this concept. An important consequence is that many extension reference-object pairs may exist within one base reference-object pair, i.e., a base reference-pair can be shared among extensions (in OOP it is not so). Thus elements in CoP exist within a hierarchy at run-time just as at compile-time. This hierarchy is analogous to the conventional postal addresses where many streets exist in one city, many houses exist in one street and so on. In our example, inclusion is used to include many buttons into one parent panel and therefore we say that one button is IN a panel. In contrast, in OOP if a button class inherits a panel class then one button IS a panel at run-time. Button within a panel are distinguished by their references (described in the reference class). Another important difference from OOP is that parts of objects in CoP (base and extensions) are represented by their own references and may have different locations. So panel object may have one address in memory while button object has another location, for example, on disk.

Panels themselves may have a reference class and hence we can have many panels each having many buttons. In order to uniquely represent a button we need to specify its panel reference and its button reference within this panel. Such a reference consisting of many segments is referred to as complex reference. If concept Panel also has a parent concept then a fully quantified reference will include more segments. When an indirectly represented object is accessed, say, a button is clicked, then the complex reference has to provide access to the object. It is done automatically by a so called continuation method.

One principle of CoP is that parent reference methods override child reference methods (while child object methods still override base object methods). In particular, panel reference will intercept all access requests to its child objects such buttons or labels or icons (all existing inside this panel). Normally such base reference methods are used to inject some additional behaviour or to wrap target object methods into some common function. For example, base reference methods might draw background, perform security checks etc. In other words, reference methods play a role of incoming methods of some scope like panel or button. Using reference methods the programmer can describe intermediate functionality executed implicitly behind the scenes during object access. In other words, they are responsible for functions which are triggered automatically when an access request intersects some space border.

A concept-oriented program uses concepts instead of classes. In particular, concepts are used to declare a type of variables, fields, parameters and return values. The difference from OOP is that objects in CoP are represented and accessed indirectly. This allows the programmer to describe intermediate functionality which is triggered automatically when method calls intersect space borders described by concepts. For example, a single method call button.click() might implicitly trigger rather complex processes which are executed when the target object is being accessed.

More information on the concept-oriented programming can be found at the concept-oriented portal here http://conceptoriented.org. It also includes information on the ConceptOrientedModel and other related issues.

This is an interesting idea, but I'm finding it difficult to grasp how it would work in practice. Would you consider producing some simple examples of code or pseudocode, either here or on your Web site, to illustrate? In particular, it would be helpful to see how ConceptOrientedProgramming differs from and/or extends (say) ObjectOrientedProgramming. -- DaveVoorhis

There is a name space collision here. As far as I know, BrianMcConnell? originated this term in the June 1999 issue of DrDobbsJournal, but is using it to describe something different. This term appears again in Brian's book Beyond Contact published by O'Reilly in 2001. I don't know how to resolve issues like this, but you might want to be informed of this. When I use this term, I'm referring to Brian's definition, not this one. -- JonRiehl

I am interested in how this work may relate to the proposal to have concepts in C++, see ConceptCpp. -- JohnFletcher

People need to be aware that ConceptOrientedProgramming shares its TLA with another technique of programming: ContextOrientedProgramming?.

OK, I read the whole paper at http://conceptoriented.org/papers/CopInformalIntroduction.html ("Informal Introduction into the Concept-Oriented Programming" by AlexandrSavinov)

And I'm not impressed.

It looks like the ConceptOrientedProgramming style could be achieved in ObjectOrientedProgramming languages with consistent adherence to InterfaceBasedProgramming and the ProxyPattern. (The paper does mention proxies several times, reinforcing this idea.) The "Concept" side of ConceptOrientedProgramming seems to address name-to-object mapping issues addressed by JNDI (JavaNamingAndDirectoryInterface) or the Moniker pattern (MicroSoft IMoniker interface).

I, at least, find coding in a TuringTarpit to be unproductive, so I tend to observe related achievements as proof-of-concept, and their use as proof-of-value, rather than arguments against an idea. Admittedly, I'm also not impressed that COP is helping me achieve any NonFunctionalRequirements, but it irritates me to see 'X could be achieved in Y' as implicit explanation for 'I'm not impressed.' (related: DesignPatternsAreMissingLanguageFeatures).

The paper describes the use of AspectOrientedProgramming in ObjectOrientedProgramming languages to address cross-cutting concerns.

I wonder what ConceptOrientedProgramming may offer above and beyond the above.

Observations about the paper:

They completely confuse inheritance with containment. See "Figure 4": They're criticizing the limitations of using inheritance when containment should have been used.
They don't understand that AOP Advice is defined independently of point cuts.
COP seems particularly weak, in comparison to AOP, with regard to mixing in multiple cross-cutting concerns in a single class, or distributing a single cross-cutting concern across multiple concept hierarchies. COP seems to suffer from a "single inheritance hierarchy" problem when one needs to do cross-cutting concern mixins.
They assume that ALL object instances are persisted and shared between processes. This may be good for database and remote system access, but doesn't seem to address local code and data organization.
VERY strong hierarchical relationships are assumed, and these are baked into the design early. This could suffer from similar problems that plagued HierarchicalDatabases. (see LimitsOfHierarchies)
Objects are loaded and saved at every method access. I see no provision for transactions that span multiple method calls. This could be really bad for most business applications.
Their analogies are strained. And not necessarily applicable to software development in general.

Hmmm... You know, it's gonna be kinda hard to do much ConceptOrientedProgramming for a while because

 "Currently there are no concept-oriented programming languages"

as stated by the paper's author at http://conceptoriented.org/forums/viewtopic.php?f=3&t=6#p8

-- JeffGrigg

I have found the following in the Conclusions of the introductory paper, http://conceptoriented.org/papers/CopInformalIntroduction.html:

: The solution based on concepts could be informally compared with the introduction of complex numbers in mathematics which also have two constituents: real part and imaginary part. As a result of such mathematical generalization formulas and manipulations get much simpler and more natural in comparison with the conventional real numbers. The same effect is achieved in programming by introducing concepts instead of classes: programs get much simpler and their logic is expressed more naturally and elegantly when we manipulate pairs of references (imaginary part) and objects (real part).

That seems to me to give some insight into the thinking of the author, AlexandrSavinov, who is the only author he references. It also gives a clue as to how to implement the ideas, using a tuple object in e.g. CeePlusPlus to as a basis. -- JohnFletcher

I could implement this as a Java code generator, using Java DynamicProxy?s to implement the reversed method overriding conventions of concept references. (Would need an additional proxy for each level of parent reference calling to a 'sub' reference level, but that wouldn't be hard.)

I do hit a stumbling block where references use the 'object' keyword to call their object instances: This seems to assume that the object for each reference is in memory, as the reference isn't implementing code, like serialization and deserialization, or creating objects from database data. So this seems to imply to me that concept references could lookup their objects, using their concept identifiers, right when the references are created. (IE: in a reference "constructor" method.)

This makes me think that ConceptOrientedProgramming is not as general as claimed, as it would need some as yet unspecified way for reference definitions to explicitly define how one transforms reference keys to object instances. That is, is needs something more than just an "object." keyword. -- JeffGrigg

ConceptOrientedProgramming formalizes spaces by formalizing object-identity and capturing messaging automatically by having the outer-space serve ProxyObjects? for the objects (or 'concepts') held within. I believe that formalizing the concept of 'spaces' is a fine idea. It allows for useful features to be developed, such as local optimizations while still integrating with global distribution, the ability to provide ContainerManagedPersistence at the level of 'spaces', a natural unit of runtime modularity (as opposed to source modularity), allowance for HotSwapping code in a given space by delaying events at space borders, support for code-chunking and distribution, and elimination of global variables in the 'global' sense while still allowing globals to be local to a parent space.

That said, it is my impression that ConceptOrientedProgramming is an unnecessarily complicated approach to achieving these goals. It looks to me that each concept, such as Button, is being specialized based on its location (e.g. Button in a Panel, Button on a Train, Button in the Rain, Button on Green Eggs and Ham) in addition to having the normal ObjectOriented specialization in its properties (e.g. RadioButton, EggButton, HamButton). This implies an enormous specialization burden on the programmers. If we had asynchronous MessagePassing between objects, would we further specialize concepts as RedButton? in a Panel on a MessageQueue?

I would prefer approaches to managing spaces that allows programmers of a component to be ignorant of the space in which that component shall reside. In designs I've been working with, doing so requires that 'objects' (or 'actors' in my case) be constructed with references to 'resources' available in their local environment, and that the environment or locality provide these resources. Usefully, in addition to the normal benefits of controlling interaction with environment, this provides a mechanism for mobile code (a mobile code chunk is an abstract unit of code that needs a set of local resources in order to run) and supports coordination languages for actor/process configurations and DataflowProgramming.

A particularly well built group of EndemeSets could be used to wrap data in a UniversalIdentification? using the potential of EnDemes and EndemePaths to wrap data. This would meet the requirements of 'concepts' as described. However I have not figured out to do this yet. -- JonGrover

JanuaryZeroNine

CategoryInformationOrientation