Concept-Oriented Programming: References, Classes and Inheritance Revisited
Total Page:16
File Type:pdf, Size:1020Kb
Concept-Oriented Programming: References, Classes and Inheritance Revisited Alexandr Savinov Database Technology Group, Technische Universität Dresden, Germany http://conceptoriented.org Abstract representation and access is supposed to be provided by the translator. Any object is guaranteed to get some kind The main goal of concept-oriented programming (COP) is of primitive reference and a built-in access procedure describing how objects are represented and accessed. It without a possibility to change them. Thus there is a makes references (object locations) first-class elements of strong asymmetry between the role of objects and refer- the program responsible for many important functions ences in OOP: objects are intended to implement domain- which are difficult to model via objects. COP rethinks and specific structure and behavior while references have a generalizes such primary notions of object-orientation as primitive form and are not modeled by the programmer. class and inheritance by introducing a novel construct, Programming means describing objects but not refer- concept, and a new relation, inclusion. An advantage is ences. that using only a few basic notions we are able to describe One reason for this asymmetry is that there is a very many general patterns of thoughts currently belonging to old and very strong belief that it is entity that should be in different programming paradigms: modeling object hier- the focus of modeling (including programming) while archies (prototype-based programming), precedence of identities simply serve entities. And even though object parent methods over child methods (inner methods in identity has been considered “a pillar of object orienta- Beta), modularizing cross-cutting concerns (aspect- tion” [Ken91] their support has always been much weaker oriented programming), value-orientation (functional pro- in comparison to that of entities. Another reason is that gramming). Since COP remains backward compatible hiding the structure of references and the design of access with object-oriented programming, it can be viewed as a procedures is a very successful pattern which, particular- perspective direction for developing a simple and natural ly, accounts for the success of OOP. Indeed, we are inter- unified programming model. ested only in what this object does rather than how it is Keywords programming paradigms; concept-oriented being accessed, and we want to abstract from the repre- programming; classes; inheritance; polymorphism; refer- sentation and access details when manipulating objects. ences; cross-cutting concerns. However, this abstraction from reference mechanics is achieved by sacrificing the possibility to model these 1. Introduction functions at all by completely removing references and Object orientation is one of the most influential and suc- object access procedures from the scope of programming cessful paradigms in computer science. Much of its power and delegating these functions to the translator. In OOP, comes from the ability to express a wide variety of real- we are not able to model how objects exist, where they world situations using only a few relatively simple con- exist, and how they are accessed. cepts the main of which is that of object. Objects have Concept-oriented programming (COP) (first described always been in the center of this methodology (hence its in [Sav05a]) is a novel approach to programming the name) according to which it is object’s functionality that main general goal of which is to answer these questions accounts for most of the program complexity. In other by legalizing references and making them first-class ele- words, a program is a number of objects possessing some ments of programming languages. In this sense, COP can behavior and responding to messages, and to describe a be characterized as reference-oriented programming or program means to describe objects it consists of. programming focusing on what happens during access. It Although object-oriented programming (OOP) has is assumed that references account for a great deal of the been proven to be extremely successful, it has one general program complexity and their functions are at least as drawback: it does not provide a means for describing how important as those of objects. For example, in the follow- objects are represented and how they are accessed. Strict- ing typical object-oriented program we create an object ly speaking, it is not a drawback but rather a consequence representing a bank account and then call its method: of its main assumption that everything should be de- Account acc = new Account(); scribed by objects. As a result, the mechanism of object acc.setInitialBalance(100.00); 1 In OOP, it is not possible to specify our own custom for- with custom structure (like postal addresses). Defining mat of references for the bank account object although it program elements as consisting of two parts and existing would be natural to use a domain-specific format like in a hierarchical address space leads to rethinking and account number. And we are not able to provide our own generalizing such fundamental notions as object identifi- access procedure even though it is natural that any access cation, inheritance and polymorphism. to this object has to be somehow controlled. All variables First version of concept-oriented programming is de- store only platform-specific (primitive) references and the scribed in [Sav05a] and is denoted as COP-I. The next translator creates the illusion of instantaneous object ac- version, described in [Sav08a, Sav09a, Sav08b] and de- cess without any possibility to specify domain-specific noted as COP-II, changes the interpretation of concepts intermediate actions. and adds several new mechanisms. This paper is a full COP changes this view by making references active version of the paper [Sav12a] describing a new major elements of the program with arbitrary structure and be- revision of concept-oriented programming, denoted as havior. For example, bank accounts can be represented COP-III. The main goal of the third revision is to describe directly by account numbers and have functions responsi- this programming model by using fewer general notions ble for access to the account object. To describe both and more natural interpretations by simultaneously cover- references and objects, COP introduces a novel construct, ing more programming patterns existing in other ap- called concept (hence the name of this approach). The proaches. main goal of concepts is to retain main functions of con- The first major change in COP-III is that concepts are ventional classes by providing a possibility to model how defined differently: instead of using two constituents – objects are represented and accessed. In previous versions object class and reference class – we use only one con- of COP [Sav08a, Sav09a, Sav08b], concept was defined stituent which models references. Thus objects are effec- as a couple of two classes: one object class and one refer- tively excluded from the model as a structural element. If ence class. For example, a bank account concept is de- COP-I and COP-II treat references and objects as two fined as follows: symmetric constituents then COP-III makes references concept Account { more important than objects. Yet, objects are still fully reference { // Reference class supported in the model. Instead of modeling them explic- char[10] accNo; itly via object classes, we propose a new general treat- } object { // Object class ment: objects are functions of their references. In COP- double balance; III, this definition is made more specific: objects are de- } fined via outgoing methods of concepts. Thus program- Since references and objects are symmetric, programming ming in COP-III is reduced to describing locations can be viewed as consisting of two orthogonal branches. (references) and their functions (objects). For modeling On one hand, we can model references and their behavior. duality, COP-III uses two kinds of methods – incoming On the other hand, we can model objects. methods and outgoing methods – instead of using two An important point is that reference and object classes kinds of classes – reference class and object class. are defined only together, that is, a concept has one name Another important change is the use of two keywords for both its constituents. When concepts are used, they are for navigating through the hierarchy, super and sub (as undistinguishable from classes. For example, a variable of opposed to using only super in OOP), and the existence of the Account concept is declared as usual: two opposite overriding strategies. This allows us to treat any element as a domain, scope or context consisting of Account acc; many internal child elements. Incoming methods of con- In contrast to OOP, it will always store a reference in the cepts intercept requests from outside and outgoing meth- format specified by in the reference class of the concept ods intercept requests from inside. while the object is accessed indirectly using this concept COP-III also removes the reference resolution mecha- access methods. If reference class is empty then it will be nism and continuation method from the programming provided by the translator so we get conventional classes. model. Instead, access indirection relies on the ability of If object class is empty then such concepts describe val- elements to intercept incoming and outgoing methods. ues. In the general case, the programmer can freely vary The paper has the following layout. Section 2 provides what part of an element is passed by-value and by- general background and motivation for COP by describ- reference. ing its design goals and basic principles. Section 3 defines Classical inheritance cannot be easily adopted for con- the notion of concept and how concepts are used for cepts, particularly, because concept instances exist in a modeling objects and references. Section 4 is devoted to hierarchy (like objects in prototype-based programming). describing inclusion relation and how it is used for model- Therefore a new relation was introduced, called inclusion.