No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
The Interpretation of Object-Oriented Programming Languages
Abstract
Object-oriented languages are probably the most important development in computing for many years. They allow us to describe and to model the phys ical as well as more abstract worlds. They allow us to provide the computa tional entities we describe with a dynamics that is encapsulated, thus leading to a more distributed notion of state, a notion which, inter alia, makes pro gramming and analysis somewhat more tractable. Unfortunately, if one wants to understand the concepts that are currently employed in object-oriented languages, one must refer to the proceedings of conferences such as OOPSLA or EGOOP. These proceedings might be hard to obtain or obscure; in any case, without a background in the area, the reader will, almost certainly encounter concepts which will send them back to the literature. The aim of this book is to provide, in one place, an interpretation of the primary concepts in object-oriented programming languages. In some cases, for example, multiple inheritance, there is no single interpretation that is accepted by all; in such cases, the different approaches are explained. An attempt has been made to be as comprehensive as possible, but certain con cepts have been omitted for the reason that they are not often encountered or they have fallen from grace. The concept of the instantiable module appears to be one example of this.
... In Codecharts, a special status is reserved to sets of methods that share the same signature (name and argument types) throughout an inheritance hierarchy, to which we refer as clans ( §7.3). 1 The numerous merits of object-oriented programming have been discussed extensively in the literature; see, for example, Wirfs-Brock et al. [1990]. 2 What follows are not definitions. We recommend Wirfs-Brock et al. [1990] and Craig [2000] as sources of detailed information about these terms. These abstraction mechanisms motivate our answer to the ontological question (p. ...
... These vary largely by the interpretation given in each programming language. Craig [2000] divides object-oriented programming languages into prototype-based and class-based languages. We 3 Note that the programming language is not the only factor: One may write procedural programs in an object-oriented programming language such as Java. ...
... Such methods can be modelled using a stand-alone signature, such as the global function sort in Codechart 15. In multiple-dispatch programming languages such as CLOS [Craig 2000], a method can be a "member" of one, two, or more classes, in which case it is modelled as method multiply in Codechart 15. In conclusion, methods are c06.pdf ...
... However, "it appears prototype-based programming is better suited to exploratory or experimental programming than with production methods" [Craig, 2000]. Therefore we focus our attention on class-based, and therefore statically typed, languages. ...
... Dynamic binding is closely associated with the principle of inheritance, which we briefly discussed in the previous subsection. "Dynamic binding means that the operation that is executed when objects are requested to perform an operation is the operation associated with the object itself and not with one of its ancestors" [Craig, 2000]. For example, consider method m defined in c super and overridden by m in c sub , and a variable x of type c super . ...
... Another example is ad-hoc polymorphism [Craig, 2000], often interpreted as method overloading: methods that share the same method name, but differ in the types of their arguments. For example, the methods add(int , int ) and add (String , String ) defined in class c are overloaded as they share the same method name (add), but differ in their argument types. ...
... Given by a pair of objects, it is always possible to determine whether they are the same or different. Objects are composed of data and operations; the operations associated with an object typically act upon the data which it contains [17]. ...
... There is two kind of languages that support OOP [17]: pure and impure languages. The firsts include only construct that directly relates to OOP. ...
Object Orientated Paradigm (OOP) allows to build software models more maintainable and easier to understand; however, teachers who teach OOP in a beginners course have an extraordinary challenge. There are alternative approaches to traditional teaching such as Intelligent Tutoring Systems; these systems have made use of ontologies to represent domain knowledge. There are some efforts to build ontologies in the OOP area; however, previous proposals are too general or based on concepts of programming without considering the foundations of OOP. So, there is not an ontology with the minimum concepts to be utilized by Intelligent Tutoring Systems. The aim of this work is to develop an ontology that can represent the knowledge of OOP to be used in educational systems. We built the ontology considering part of concepts of an undergraduate course and following the phases: specification, conceptualization, formalization, and implementation. This work acquired a knowledge representation structure to be a significant support to teach courses of Object Orientation based on Intelligent Tutoring Systems.
... To program computational tasks for Physarum machines, we are developing a new object-oriented programming language [5], [6], [7], called a Physarum language. The Physarum language is a prototype-based language [8] consisting of inbuilt sets of prototypes corresponding to both the high-level models used for describing behaviour of Physarum polycephalum (e.g., ladder diagrams, transition systems, timed transition systems, Petri nets) and the low-level model (distribution of stimuli). More information is given in Section II. ...
... Our language is based on the prototype-based approach (cf. [8]) that is less common than the class-based one, although, it has a great deal to offer. This approach is also called classless or instance-based programming because prototype-based languages are based upon the idea that objects, representing individuals, can be created without reference to class-defining. ...
... A class serves as a prototype for instances. Our mechanism, therefore, is closely related to prototype-based languages (see chapter 3 of [29], for example), but with a twist. In order to ensure that the class mechanism operates entirely at the abstract syntax level, classes in Ptolemy II are purely syntactic objects and play no role in the execution of a model. ...
... 29. The output of the simple signal processing model in figure 2.25 with noise power = 0.01Using Vergilpan window, it is easy to navigate around the entire model. ...
... ♦ Strategic statements are in a_ ♦ Tactical statements are in _\ ♦ Implementation statements are in _X Some of the implications of the Intension/Locality hypothesis are illustrated in Figure 3. ( 6 ) An earlier version of the hypothesis was presented in the 25th International Conference on Software Engineering [13]. The Locality criterion was revised in [11]. ...
... Information Hiding, sometimes referred to as data abstraction or encapsulation, is a software design principle supported (in one variation or another) by every object-based and class-based language [6]. The C++ compiler, for example, allows the programmer to define any class member ( 8 ) as 'private'. ...
We distinguish three abstraction strata in software design statements: (i) Strategic design statements ('architectural design') determine global constraints, such as programming paradigms, architectural styles, component-based software enginering standards, design principles, and law-governed regularities; (ii) Tactical design statements ('detailed design') determine local constraints, such as design patterns, programming idioms, and refactorings; (iii) Implementation statements determine specific properties of the implementation, such as a class diagrams and program documentation. Seeking to ground this intuition in a well-defined vocabulary, we define two criteria of distinction in mathematical logic. We present the Intension/Locality hypothesis, postulating that the spectrum of software design statements is divided into three well-defined 'abstraction classes' as follows: (i) the class of non-local statements (N L) contains Strategic statements; (ii) the class of local and intensional statements (L I) contains Tactical statements; and (iii) the class of local and extensional statements (L E) contains Implementation statements. We demonstrate a broad range of software design statements that corroborate our hypothesis. We conclude with a proof of the architectural mismatch theorem, according to which architectural mismatch arises from attempting to combine components that assume conflicting non-local statements.
... However, the concept did not gain popularity until the1980s and 1990s when some of the later languages such as "smalltalk", "objective C", "C++", etc. appeared (Rumbaugh, Jacobson, & Booch, 1999). An OOL must have certain characteristics, such as encapsulation, inheritance, polymorphism, and dynamic binding in order for it to be considered an OOL (Craig, 2007); however, these concepts are taught in software engineering and are beyond the scope of this paper. For example, "C" programming language is not an OOL because it does not have all of the mentioned characteristics. ...
... Nevertheless, no solution has been found that might be considered satisfactory for all the problems raised by the multiple inheritance mechanisms. A detailed discussion of these problems can be found in [55]. Logtalk multiple inheritance support will be discussed later in this section. ...
iii “There are no answers, only choices.” Gibarian to Kelvin in “Solaris”, Steven Soderbergh’s movie based on Stanislaw Lem novel of the same name “Não existem respostas, somente escolhas.” Gibarian para Kelvin, no filme “Solaris ” realizado por Steven Soderbergh, baseado no livro de Stanislaw Lem com o mesmo nome
... In [3], the definition of class contains the definition of slots. There are two types of slots: one is used to hold the data and the other is used to hold the procedural code that implement the operations defined for the class. ...
Object-oriented programming has advantages of reusability, more extensibility, and easier maintainability. While it needs hardware/software environment to support the OO behaviors. In the paper, three OO supporting mechanisms are discussed, the advantages and disadvantages are compared.
... In [3], the definition of class contains the definition of slots. There are two types of slots: one is used to hold the data and the other is used to hold the procedural code that implement the operations defined for the class. ...
Object-oriented programming has advantages of reusability, more extensibility, and easier maintainability. While it needs hardware/software environment to support the OO behaviors. In the paper, three OO supporting mechanisms are discussed, the advantages and disadvantages are compared.
... Nevertheless, no solution has been found that might be considered satisfactory for all the problems raised by the multiple inheritance mechanisms. A detailed discussion of these problems can be found in [55]. Logtalk multiple inheritance support will be discussed later in this section. ...
... In contrast, techniques idiosyncratic to the objectoriented programming (OOP) paradigm, such as inheritance and dynamic binding (Craig, 1999), induce regularities of a unique nature. Consequently, O-O systems deviate considerably from other systems in their architectures. ...
Progress was made in the understanding of object-oriented (O-O) design through the introduction of patterns of design and architecture. Few works, however, offer methods of precise specification for O-O design.
This article provides a well-defined ontology and an underlying framework for the formal specification of O-O design: (1) We observe key design motifs in O-O design and architectures. (2) We provide a computational model in mathematical logic suitable for the discussion in O-O design. (3) We use our conceptual toolkit to analyze and compare proposed formalisms.
... The patterns catalogue [8] discusses the problem of representing abstract syntax trees and operations thereon. It is argued that, ideally, the most flexible implementation is one written in a programming language that supports double dispatch [4]. However the programming languages at the focus of the authors (C++ and Smalltalk in [8], but also neither in most other O-O programming languages such as Java and C#) do not support such a mechanism, which motivates the Visitor pattern as a design policy. ...
Flexibility has been recognized as a desirable quality of software since the earliest days of software engineering. Classic and contemporary software design literature suggest that particular implementations are more flexible than others but stop short of suggesting objective criteria for quantifying such claims. To measure software flexibility in precise terms, we introduce the notion of evolution complexity and demonstrate how it can be used to measure and compare the flexibility of—
1. programming paradigms (object-oriented vs. procedural programs)
2. architectural styles (Shared Data, Pipes and Filters, and Abstract Data Type)
3. design patterns (Visitor and the Abstract Factory)
We also demonstrate how evolution complexity can be used to choose the most flexible design policy. We conclude with experimental results corroborating our claims.
... This appendix describes a few object-oriented concepts involved in the Visitor Design Pattern and their Java-specific behaviour. Further explanations can be found in [Cra00] and [Fla97]. ...
Aspect-Oriented Programming (AOP) is a recently proposed programming paradigm which promotes clear design and re-usability by enforcing the principle of separation of concerns. Procedural and object-oriented paradigms are usually not sufficient for separating the concerns in such a way that none of them ends up being scattered throughout the code. AOP introduces the concept of aspects, which are a means to encapsulate crosscutting concerns (i.e. concerns which cannot be encapsulated in a single unit of decomposition, or cannot be neatly separated from other concerns in a component). AOP is an enhancement to other programming paradigms. Three different AOP schemes AspectJ, JAC and DJ, which are all aspect-oriented extensions to Java are investigated and compared. The manner in which aspect-oriented constructs interact with Java is studied. The parallelisation of matrix multiplication is taken as an example in order to show the use of AOP, and more particularly AspectJ, from the design of an operation through to its integration into existing applications. This parallelisation appears to be a means to introduce performance as an aspect. The aspects used in this example are then enhanced so as to use abstraction and reflection in order to improve their own re-usability. It is concluded that AOP is a promising technology for improving readability and re-usability of components, and for introducing performance into applications.
... Self [21], JavaScript [15], Kevo [37], Omega [4]) are considered. Such languages contain no classes; instead, each object is also a prototype [13]. Objects can be copied exactly (effectively creating a new instance), or they can be copied and then modified (effectively creating a new class). ...
The objective of this paper is to analyze combinations of software configuration management (SCM) and object-oriented (OO) systems that synergistically increase the e#ectiveness of both systems. After reviewing the two areas, the central concepts of each are shown to be analogous to one another. The paper then diverges to look at existing literature by considering reification of variants and attempts at producing SCM object models. It is then proposed that SCMs could better serve in OO environments by working at a higher-level than the file model. Finally, a holistic approach to software is proposed that fully integrates the design and implementation aspects of OO techniques and the management aspect of SCMs. 1 Introduction This paper explores applications --- both extant and novel --- of marrying software configuration management (SCM) systems and object-oriented (OO) techniques. The most straightforward way to do this is by applying object-oriented analysis and design (OO...
Programmierwerkzeuge, die verschiedene Programmiersprachen unterstützen und sich konsistent bedienen lassen, sind hilfreich für Softwareentwickler, weil diese sich nicht erst mit neuen Werkzeugen vertraut machen müssen, wenn sie in einer neuen Sprache entwickeln wollen. Außerdem ist es nützlich, verschiedene Programmiersprachen in einer Anwendung kombinieren zu können, da Entwickler dann Softwareframeworks und -bibliotheken nicht in der jeweiligen Sprache nachbauen müssen und stattdessen bestehende Software wiederverwenden können. Dennoch haben Entwickler eine sehr große Auswahl, wenn sie nach Werkzeugen suchen, die teilweise zudem speziell nur für eine Sprache ausgelegt sind. Einige integrierte Entwicklungsumgebungen unterstützen verschiedene Programmiersprachen, können aber häufig keine konsistente Bedienung ihrer Werkzeuge gewährleisten, da die jeweiligen Ausführungsumgebungen der Sprachen zu verschieden sind. Darüber hinaus gibt es bereits Mechansimen, die es erlauben, Programme aus anderen Sprachen in einem Programm wiederzuverwenden. Dazu werden häufig das Betriebssystem oder eine Netzwerkverbindung verwendet. Programmierwerkzeuge unterstützen jedoch häufig eine solche Indirektion nicht und sind deshalb nur eingeschränkt nutzbar bei beispielsweise Debugging Szenarien. In dieser Arbeit stellen wir einen neuartigen Ansatz vor, der das Programmiererlebnis in Bezug auf das Arbeiten mit mehreren dynamischen Programmiersprachen verbessern soll. Dazu verwenden wir die Werkzeuge einer Smalltalk Programmierumgebung wieder und entwickeln eine virtuelle Ausführungsumgebung, die verschiedene Sprachen gleichermaßen unterstützt. Der auf unserem Ansatz basierende Prototyp Squimera demonstriert, dass es möglich ist, Programmierwerkzeuge in der Art wiederzuverwenden, sodass sie sich für verschiedene Programmiersprachen gleich verhalten und somit die Arbeit für Entwickler vereinfachen. Außerdem ermöglicht Squimera einfaches Wiederverwenden und darüber hinaus das Verschmischen von in unterschiedlichen Sprachen geschriebenen Softwarebibliotheken und -frameworks und erlaubt dabei zusätzlich Debugging über mehrere Sprachen hinweg.
From the previous chapter we know that the opportunity of implementing decidable arithmetic functions on the amoeboid motions means that we can design an unconventional computer using amoeboid organisms. In this chapter, I am going to propose a kind of this computer designed on Physarum polycephalum. Designing computers on swarms (such as plasmodia or ant nests) would mean that behaviourism is valid indeed, that is, we can control the swarm behaviours by placing attractants and repellents. Nevertheless, this claim is only partly true, because we can implement undecidable arithmetic functions also.
This book has concentrated on a traditional and intuitive view of a compiler as a program to translate from a high-level source language to a low-level target machine
language, with a potentially visible intermediate representation between a front-end and a back-end. This form of compiler is in essence specified by the source and target languages and also by the language in which the compiler should be coded. But this book has also stressed that the view of a compiler as a single, monolithic piece of code is not helpful. Instead, regarding it as a collection of phases, at least by separating a front-end from a back-end, is very helpful. These issues become particularly important when considering a strategy for a programming language implementation project.
We propose two unconventional arithmetic circuits: adder and subtracter defined on finite p-adic integers. These circuits are theoretically implemented on the plasmodium of Physarum polycephalum. Adder and subtracter are designed by means of spatial configurations of several attractants and repellents which are stimuli for the plasmodium behaviour. As a result, the plasmodium could form a network of protoplasmic veins connecting attractants and original points of the plasmodium. Occupying new attractants is considered in the way of adders and leaving some attractants because of repelling is considered in the way of subtracters. On the basis of p-adic adders and subtracters we can design complex p-adic valued arithmetic circuits within a p-adic valued logic proposed by us.
A Physarum machine is a biological computing device implemented in the plasmodium of Physarum polycephalum or Badhamia utricularis which are one-cell organisms able to build complex networks for solving different computational tasks. The plasmodial stage of such organisms is a natural transition system which can be considered the medium for bio-inspired strategy games. In the paper, we describe a rough set approach for description of a strategy game created on the Physarum machine. The strategies of such a game are approximated on the basis of a rough set model, describing behavior of the Physarum machine, created according to the VPRSM (Variable Precision Rough Set Model) approach. Theoretical foundations given in the paper are supplemented with description of a specialized programming language for Physarum machines, as well as a software tool developed, among others, for simulation of Physarum games.
The main goal of the paper is to describe essential aspects of a new object-oriented programming (OOP) language, called the Physarum language, for Physarum machines. A Physarum machine is a biological computing device experimentally implemented in the plasmodium of Physarum
polycephalum, a single cell organism, also called true slime mould. The main attention is focused on a language specification based on selected high-level models describing behaviour of Physarum machines as well as a computer tool created for parsing the Physarum language statements and producing a machine code that is, in case of Physarum machines, a spatial distribution of stimuli.
The Generic Modeling Environment (GME) is a con-figurable tool suite that facilitates the rapid creation of domain-specific model-integrated program synthesis environments. There are three characteristics of the GME that make it a valuable tool for the construction of domain-specific modeling environments. First, the GME provides generic modeling primitives that assist an environment designer in the specification of new graphical modeling environments. Second, these generic primitives are spe-cialized to create the domain-specific modeling concepts through meta-modeling. The meta-models explicitly support composition enabling the creation of composite modeling languages supporting multiple paradigms. Third, several ideas from prototype-based programming languages have been integrated with the inherent model containment hierarchy, which gives the domain expert the ability to clone graphical models. This paper explores the details of these three ideas and their implications.
LePUS3 is a formal design description language for specifying decidable (i.e. automatically verifiable) properties of object-oriented design. LePUS3 has been successfully applied to both design verification and reverse engineering applications. However, LePUS3 is becoming over zealously pragmatic. Its current definition is inflexible, limiting is expressivity, extensibility and reasoning capabilities. We present a new theory of classes derived from the theoretical foundations of LePUS3, and defined in the Typed Predicate Logic. The expressive power of our theory is demonstrated by specifying and reasoning over design patterns.
This volume describes the software architecture of Ptolemy II. The first chapter covers the kernel package, which provides a set of Java classes supporting clustered graph topologies for models. Cluster graphs provide a very general abstract syntax for component-based modeling, without assuming or imposing any semantics on the models. The actor package begins to add semantics by providing basic infrastructure for data transport between components. The data package provides classes to encapsulate the data that is transported. It also provides an extensible type system and an interpreted expression language. The graph package provides graph-theoretic algorithms that are used in the type system and by schedulers in the individual domains. The plot package provides a visual data plotting utility that is used in many of the applets and applications. The codegen package is a templated based code generator similar to the Ptolemy Classic code generators. The copernicus package is a code generator that performs static analysis on Java class files to produce smaller, faster executable models.
Volume 1 gives an introduction to Ptolemy II, including tutorials on the use of the software, and volume 3 describes the domains, each of which implements a model of computation
Actor-oriented languages provide a component composition methodology that emphasizes concurrency. The interfaces to actors are parameters and ports (vs. members and methods in object-oriented languages). Actors interact with one another through their ports via a messaging schema that can follow any of several concurrent semantics (vs. procedure calls, with prevail in OO languages). Domain-specific actor-oriented languages and frameworks are common (e.g. Simulink, LabVIEW, and many others). However, they lack many of the modularity and abstraction mechanisms that programmers have become accustomed to in 00 languages, such as classes, inheritance, interfaces, and polymorphism. This extended abstract shows the form that such mechanisms might take in AO languages. A prototype of these mechanisms realized in Ptolemy II is described.
The concepts of the basic entities, i.e., objects, object classes, object types, etc., in the type hierarchy of object-oriented languages are revisited. The notion of object reuse is defined and elaborated. We show that while object classes are useful in object description and creation, the class-is-type principle which is used in many object-oriented languages is inadequate for object reuse. We also show that parameterized types and generic functions are better served by using kind-bounded qualification than universal qualification and other mechanisms. Keywords: Object reuse, software integration, objects, classes, types, kinds, class-is-type principle, parameterized types, generic functions, kind-bounded polymorphism 1
ResearchGate has not been able to resolve any references for this publication.