scholarly journals Classless Object Semantics

2021 ◽  
Author(s):  
◽  
Timothy Jones
Keyword(s):  
Programming Languages ◽  
Object Oriented ◽  
Formal Theory ◽  
Theoretical Models ◽  
Language Design ◽  
Trade Offs ◽  
Practical Design ◽  
Integral Role ◽  
Object Oriented Languages

<p>Objects have been categorised into classes that declare and implement their behaviour ever since the paradigm of object-orientation in programming languages was first conceived. Classes have an integral role in the design and theory of object-oriented languages, and often appear alongside objects as a foundational concept of the paradigm in many theoretical models.  A number of object-oriented languages have attempted to remove classes as a core component of the language design and rebuild their functionality purely in terms of objects, to varying success. Much of the formal theory of objects that eschews classes as a fundamental construct has difficulty encoding the variety of behaviours possible in programs from class-based languages.  This dissertation investigates the foundational nature of the class in the object-oriented paradigm from the perspective of an ‘objects-first’, classless language. Using the design of theoretical models and practical implementations of these designs as extensions of the Grace programming language, we demonstrate how objects can be used to emulate the functionality of classes, and the necessary trade-offs of this approach.  We present Graceless, our theory of objects without classes, and use this language to explore what class functionality is difficult to encode using only objects. We consider the role of classes in the types and static analysis of object-oriented languages, and present both a practical design of brand objects and a corresponding extension of our theory that simulates the discipline of nominal typing. We also modify our theory to investigate the semantics of many different kinds of implementation reuse in the form of inheritance between both objects and classes, and compare the consequences of these different approaches.</p>

scholarly journals Classless Object Semantics

2021 ◽  
Author(s):  
◽  
Timothy Jones
Keyword(s):  
Programming Languages ◽  
Object Oriented ◽  
Formal Theory ◽  
Theoretical Models ◽  
Language Design ◽  
Trade Offs ◽  
Practical Design ◽  
Integral Role ◽  
Object Oriented Languages

<p>Objects have been categorised into classes that declare and implement their behaviour ever since the paradigm of object-orientation in programming languages was first conceived. Classes have an integral role in the design and theory of object-oriented languages, and often appear alongside objects as a foundational concept of the paradigm in many theoretical models.  A number of object-oriented languages have attempted to remove classes as a core component of the language design and rebuild their functionality purely in terms of objects, to varying success. Much of the formal theory of objects that eschews classes as a fundamental construct has difficulty encoding the variety of behaviours possible in programs from class-based languages.  This dissertation investigates the foundational nature of the class in the object-oriented paradigm from the perspective of an ‘objects-first’, classless language. Using the design of theoretical models and practical implementations of these designs as extensions of the Grace programming language, we demonstrate how objects can be used to emulate the functionality of classes, and the necessary trade-offs of this approach.  We present Graceless, our theory of objects without classes, and use this language to explore what class functionality is difficult to encode using only objects. We consider the role of classes in the types and static analysis of object-oriented languages, and present both a practical design of brand objects and a corresponding extension of our theory that simulates the discipline of nominal typing. We also modify our theory to investigate the semantics of many different kinds of implementation reuse in the form of inheritance between both objects and classes, and compare the consequences of these different approaches.</p>

scholarly journals Block Structure and Object-Oriented Languages

1987 ◽  
Vol 16 (230) ◽  
Author(s):  
Ole Lehrmann Madsen
Keyword(s):  
Programming Languages ◽  
Block Structure ◽  
Object Oriented ◽  
Type Checking ◽  
Run Time ◽  
Name Binding ◽  
Time Type ◽  
Object Oriented Languages

Programming languages that support the object-oriented perspective on programming may be divided into two groups. One group of languages originating from Simula follows the Algol tradition with respect to block structure, static name binding and compile-time type checking. Another group of languages originating from Smalltalk is more in the style of the Lisp tradition with a flat set of definitions (classes), dynamic name binding and run-time type checking. The purpose of this paper is to analyze the role of block structure in object-oriented languages. It will be demonstrated that block structure is useful from both a conceptual and technical viewpoint.

Fault-Tolerant Protocols Using Fault-Tolerance Programming Languages

2009 ◽  
pp. 161-174
Author(s):  
Vincenzo De Florio
Keyword(s):  
Fault Tolerance ◽  
Programming Languages ◽  
Programming Language ◽  
Fault Tolerant ◽  
Object Oriented ◽  
Significant Part ◽  
Functional Languages ◽  
Failure Handling ◽  
Run Time ◽  
Object Oriented Languages

The programming language itself is the focus of this chapter: Fault-tolerance is not embedded in the program (as it is the case e.g. for single-version fault-tolerance), nor around the language (through compilers or translators); on the contrary, faulttolerance is provided through the syntactical structures and the run-time executives of fault-tolerance programming languages. Also in this case a significant part of the complexity of dependability enforcement is moved from each single code to the architecture, in this case the programming language. Many cases exist of fault-tolerance programming languages; this chapter proposes a few of them, considering three cases: Object-oriented languages, functional languages, and hybrid languages. In particular it is discussed the case of Oz, a multi-paradigm programming language that achieves both transparent distribution and translucent failure handling.

scholarly journals Scala for generic programmers

2010 ◽  
Vol 20 (3-4) ◽  
pp. 303-352 ◽  
Author(s):  
BRUNO C. D. S. OLIVEIRA ◽  
JEREMY GIBBONS
Keyword(s):  
Programming Languages ◽  
Functional Programming ◽  
Object Oriented ◽  
Generic Programming ◽  
Functional Programming Languages ◽  
Multiple Inheritance ◽  
Functional Object ◽  
The Masses ◽  
Higher Order Functions ◽  
Object Oriented Languages

AbstractDatatype-generic programming (DGP) involves parametrization of programs by the shape of data, in the form of type constructors such as ‘list of’. Most approaches to DGP are developed in pure functional programming languages such as Haskell. We argue that the functional object-oriented language Scala is in many ways a better choice. Not only does Scala provide equivalents of all the necessary functional programming features (such as parametric polymorphism, higher-order functions, higher-kinded type operations, and type- and constructor-classes), but it also provides the most useful features of object-oriented languages (such as subtyping, overriding, traditional single inheritance, and multiple inheritance in the form of traits). Common Haskell techniques for DGP can be conveniently replicated in Scala, whereas the extra expressivity provides some important additional benefits in terms of extensibility and reuse. We illustrate this by comparing two simple approaches in Haskell, pointing out their limitations and showing how equivalent approaches in Scala address some of these limitations. Finally, we present three case studies on how to implement in Scala real DGP approaches from the literature: Hinze's ‘Generics for the Masses’, Lämmel and Peyton Jones's ‘Scrap your Boilerplate with Class’, and Gibbons's ‘Origami Programming’.

scholarly journals Multiple Dispatch in Practice

2021 ◽  
Author(s):  
◽  
Radu Muschevici
Keyword(s):  
Empirical Study ◽  
Programming Languages ◽  
Virtual Machine ◽  
Object Oriented ◽  
Run Time ◽  
Multiple Dispatch ◽  
Object Oriented Languages

<p>Multiple dispatch uses the run time types of more than one argument to a method call to determine which method body to run. While several languages over the last 20 years have provided multiple dispatch, most object-oriented languages still support only single dispatch - forcing programmers to implement multiple dispatch manually when required. This thesis presents an empirical study of the use of multiple dispatch in practice, considering six languages that support multiple dispatch. We hope that this study will help programmers understand the uses and abuses of multiple dispatch; virtual machine implementors optimise multiple dispatch; and language designers to evaluate the choice of providing multiple dispatch in new programming languages.</p>

A paradigmatic object-oriented programming language: Design, static typing and semantics

1994 ◽  
Vol 4 (2) ◽  
pp. 127-206 ◽  
Author(s):  
Kim B. Bruce
Keyword(s):  
Fixed Points ◽  
Programming Languages ◽  
Programming Language ◽  
Type System ◽  
Object Oriented ◽  
Object Oriented Programming ◽  
Language Design ◽  
Type Checking ◽  
Basic Features ◽  
Oriented Programming Language

AbstractTo illuminate the fundamental concepts involved in object-oriented programming languages, we describe the design of TOOPL, a paradigmatic, statically-typed, functional, object-oriented programming language which supports classes, objects, methods, hidden instance variables, subtypes and inheritance.It has proven to be quite difficult to design such a language which has a secure type system. A particular problem with statically type checking object-oriented languages is designing typechecking rules which ensure that methods provided in a superclass will continue to be type correct when inherited in a subclass. The type-checking rules for TOOPL have this feature, enabling library suppliers to provide only the interfaces of classes with actual executable code, while still allowing users to safely create subclasses. To achieve greater expressibility while retaining type-safety, we choose to separate the inheritance and subtyping hierarchy in the language.The design of TOOPL has been guided by an analysis of the semantics of the language, which is given in terms of a model of the F-bounded second-order lambda calculus with fixed points at both the element and type level. This semantics supports the language design by providing a means to prove that the type-checking rules are sound, thus guaranteeing that the language is type-safe.While the semantics of our language is rather complex, involving fixed points at both the element and type level, we believe that this reflects the inherent complexity of the basic features of object-oriented programming languages. Particularly complex features include the implicit recursion inherent in the use of the keyword, self, to refer to the current object, and its corresponding type, MyType. The notions of subclass and inheritance introduce the greatest semantic complexities, whereas the notion of subtype is more straightforward to deal with. Our semantic investigations lead us to recommend caution in the use of inheritance, since small changes to method definitions in subclasses can result in major changes to the meanings of the other methods of the class.

scholarly journals Multiple Dispatch in Practice

2021 ◽  
Author(s):  
◽  
Radu Muschevici
Keyword(s):  
Empirical Study ◽  
Programming Languages ◽  
Virtual Machine ◽  
Object Oriented ◽  
Run Time ◽  
Multiple Dispatch ◽  
Object Oriented Languages

<p>Multiple dispatch uses the run time types of more than one argument to a method call to determine which method body to run. While several languages over the last 20 years have provided multiple dispatch, most object-oriented languages still support only single dispatch - forcing programmers to implement multiple dispatch manually when required. This thesis presents an empirical study of the use of multiple dispatch in practice, considering six languages that support multiple dispatch. We hope that this study will help programmers understand the uses and abuses of multiple dispatch; virtual machine implementors optimise multiple dispatch; and language designers to evaluate the choice of providing multiple dispatch in new programming languages.</p>

scholarly journals The development of a method to assist in the transformation from procedural languages to object oriented languages with specific reference to COBOL and JAVA

2002 ◽  
Author(s):  
◽  
Jeanette Wendy Wing
Keyword(s):  
Programming Languages ◽  
Future Development ◽  
Paradigm Shift ◽  
Object Oriented ◽  
Specific Reference ◽  
Paradigm Shifts ◽  
Business Systems ◽  
Key Issues ◽  
Similarities And Differences ◽  
Object Oriented Languages

Computer programming has been a science for approximately 50 years. It this time there havebeen two major paradigm shifts that have taken place. The first was from “spaghetti code” to structured programs. The second paradigm shift is from procedural programs to object oriented programs. The change in paradigm involves a change in the way in which a problem is approached, can be solved, as well as a difference in the language that is used. The languages that were chosen to be studied, are COBOL and Java. These programming languages were identified as key languages, and the languages that software development are the most reliant on. COBOL, the procedural language for existing business systems, and Java the object oriented language, the most likely to be used for future development. To complete this study, both languages were studied in detail. The similarities and differences between the programming languages are discussed. Some key issues that a COBOL programmer has to keep in mind when moving to Java were identified.

scholarly journals Family Genericity

2006 ◽  
Vol 35 (578) ◽  
Author(s):  
Erik Ernst
Keyword(s):  
Object Oriented ◽  
Language Design ◽  
Design Philosophy ◽  
Extension Mechanism ◽  
Precise Knowledge ◽  
Virtual Classes ◽  
Good Support ◽  
Object Oriented Languages

Type abstraction in object-oriented languages embody two techniques, each with its own strenghts and weaknesses. The first technique is extension, yielding abstraction mechanisms with good support for gradual specification.<br />The prime example is inheritance. The second technique is functional abstraction, yielding more precise knowledge about the outcome. The prime example is type parameterized classes. This paper argues that these techniques should be<br />clearly separated to work optimally, and also that current languages fail to do this.We have applied this design philosophy to a language based on an extension mechanism, namely virtual classes. As a result, some elements based on functional abstraction have been introduced, but they are simple and only used for things where they excel; conversely, the virtual classes have become more flexible, because their role is now more well-defined.We designate the result as family genericity. The presented language design has been implemented.

Sign in / Sign up

Export Citation Format

Share Document