Instance Variables Research Articles

Protecting internal state variables from subclasses

The use of child packages to encapsulate derived tagged types and their operations should protect the state variables of the parent type that are to be manipulated by the parent operations alone. This protection can be achieved through the declaration of a data component of a limited record type, previously declared with no attributes and an access type discriminant that visibly points to an incomplete definition. The details of the data component (either scalar or composite, depending on application), whose full type declaration is in the parent package body, is accessible only through the discriminant from within the package body. This mechanism provides full information hiding of the details and maximum protection of the contents of those instance variables.

Mediator languages—a proposal for a standard

The DARPA Intelligent Integration of Information (I 3 ) effort is based on the assumption that systems can easily exchange data. However, as a consequence of the rapid development of research, and prototype implementations, in this area, the initial outcome of this program appears to have been to produce a new set of systems. While they can perform certain advanced information integration tasks, they cannot easily communicate with each other.With a view to understanding and solving this problem, there was a group discussion at the DARPA Intelligent Integration of Information/Persistent Object Bases (I 3 /POB) meeting in San Diego, in January, 1996; and a further workshop was held on this topic at the University of Maryland in April, 1996. The list of participants is in Appendix A. The idea emerging from these meeting a was not to force all systems to communicate according to specified standards, but to agree on the following:• A minimal core language, or Level 1 option, which would be a restriction of the object-oriented query language OQL, such that it will accept queries for relational databases. We recommend that all system components be able, at a minimum, to accept queries in this syntax, provided they address concepts (e.g., relations or classes, attributes or instance variables) known to that component. There must be a simple protocol to determine the schema of a system (its set of supported concepts).• A simple format for representing answers. This could also be a fragment of OQL and will be included in the core language specification.• A set of extensions, one of which could be full OQL, and would handle complex structures and abstract types (with methods). Other extensions will be needed to support rules (e.g., definitions of terms that can be shared among components), semistructured data (for self-describing objects), and shared code. A system component could support one or more of these extensions, independently, and there should be some simple protocol to determine the particular extensions that are supported.

Modular reasoning in the presence of subclassing

Considerable progress has been made in understanding how to use subtyping in a way that facilitates modular reasoning. However, using subclassing in a way that facilitates modular reasoning is not well understood. Often methods must be overriden as a group because of dependencies on instance variables, and the programmers of subclasses cannot tell which methods are grouped without looking at the code of superclasses. Also, the programmers of subclasses must look at the code of superclasses to tell what assumptions inherited methods make about the behavior of overriden methods.We present a systematic way to use subclassing that facilitates formal and informal modular reasoning. Separate specifications are given to programmers writing code that manipulates instances of a class and to programmers writing subclasses of the class. The specifications given to programmers of subclasses are divided, by division of labor specifications , into multiple parts. Subclasses may inherit or override entire parts, but not sub-parts. Reasoning about the implementation of each part is done independently of other parts.

TIGUKAT: A uniform behavioral objectbase management system

We describe the TIGUKAT objectbase management system, which is under development at the Laboratory for Database Systems Research at the University of Alberta. TIGUKAT has a novel object model, whose identifying characteristics include a purely behavioral semantics and a uniform approach to objects. Everything in the system, including types, classes, collections, behaviors, and functions, as well as meta-information, is a first-class object with well-defined behavior. In this way, the model abstracts everything, including traditional structural notions such as instance variables, method implementation, and schema definition, into a uniform semantics of behaviors on objects. Our emphasis in this article is on the object model, its implementation, the persistence model, and the query language. We also (briefly) present other database management functions that are under development such as the query optimizer, the version control system, and the transaction manager.

Introducing virtual instance variables in classes to provide sufficient support for encapsulation

Encapsulation is a technique for minimizing interdependecies among separately-writen modules by defining strict external interfaces. Many popular object-oriented languages (e.g, Smalltalk, Flavors, Objective-C and Eiffel) allow free access to inherited instances variables by descendant classes, thus denying the designer the freedom to compatibly change the represnntation of a class without affecting clients and severly compromising encapsulation. In this paper, by introducing virtual instance variables and providing two interfaces (client-interface and subclass-interface) for a class, we give a class mechanism which provides sufficent support for encapsulation and is implemented in NDOOM, a object-oriented dialect of Modula-2 which we are developing.

Theoretical aspects of object-oriented programming: types, semantics, and language design

Part 1 Objects and subtypes: user-defined types and procedural data structures as complementary approaches to data abstraction, John C. Reynolds using category theory to design implicit conversions and generic operators, John C. Reynolds. Part 2 Type inference: type inference for records in a natural extension of ML, Didier Remy type inference for objects with instance variables and inheritance, Mitchell Wand static type inference for parametric classes, Atsushi Ohori and Peter Buneman. Part 3 Coherence: a modest model of records, inheritance, and bounded quantification, Kim B. Bruce and Giuseppe Longo inheritance as implicit coercion, Val Breazu-Tannen et al coherence of subsumption, minimum typing and type-checking in F<, Pierre-Louis Curien and Giorgio Ghelli. Part 4 Record calculi: operations on records, Luca Cardelli and John C. Mitchell typing record concatenation for free, Didier Remy extensible records in a pure calculus of subtyping, Luca Cardelli bounded quantification is undecidable, Benjamin C. Pierce. Part 5 Inheritance: two semantic models of object-oriented languages, Samuel N. Kamin and Uday S. Reddy inheritance is not subtyping, William R. Cook et al toward a typed foundation for method specialization and inheritance, John C. Mitchell.

Efficient implementation of adaptive software

Adaptive programs compute with objects, just like object-oriented programs. Each task to be accomplished is specified by a so-called propagation pattern which traverses the receiver object. The object traversal is a recursive descent via the instance variables where information is collected or propagated along the way. A propagation pattern consists of (1) a name for the task, (2) a succinct specification of the parts of the receiver object that should be traversed, and (3) code fragments to be executed when specific object types are encountered. The propagation patterns need to be complemented by a class graph which defines the detailed object structure. The separation of structure and behavior yields a degree of flexibility and understandability not present in traditional object-oriented languages. For example, the class graph can be changed without changing the adaptive program at all. We present an efficient implementation of adaptive programs. Given an adaptive program and a class graph, we generate an efficient object-oriented program, for example, in C++. Moreover, we prove the correctness of the core of this translation. A key assumption in the theorem is that the traversal specifications are consistent with the class graph. We prove the soundness of a proof system for conservatively checking consistency, and we show how to implement it efficiently.

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

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.

An object-oriented representation of electromagnetic knowledge

Fundamental concepts and components in electromagnetics as well as modern field analysis techniques such as finite element analysis objects. For instance, element data and node data required by a FEM program are the instance variables where as the numerical routines are the methods in an object that represent FEM i.e. encapsulation. This approach was taken in [1]. There the device, equipotentials. zero work lines and heuristics were represented as objects. This is an unified way to represent information irrespective of their kind. In other words it does not matter whether an item is a device or a piece of executable code. The CLOS is used as the programming language.

Audition (abstract)

This demonstration presents Audition, an object-oriented language and environment designed to allow the easy creation of visual and interactive programs. It uses a metaphor of Performers and Stages, as first inspired by the XEROX Pam Rehearsal World project. Performers are the main interaction units. They are visible and mouse or message activated; sample types include DisplayPerformers, Turtles, Graphs, and Gauges. Performers are grouped on Stages; stages maintain local name spaces so that Performers can be named and intercommunicate using their local names. While Performers are members of a class, they may also be specialised through the addition of instance-specific behaviour and structure; this may also be inherited from other performers. Just as inheritance models is-kind-of relationships, performers collected on a stage visibly and logically model is-part-of relationships, in a more flexible way than instance variables. An application is usually just a specialised stage and its specialised performers. The performer-stage paradigm gives rise to models that are at once well factored across their participating performers and yet are fully encapsulated within a stage. Audition is a threaded interpreted language implemented in itself. At present we are using Audition to investigate planning aids and simulations for industrial situations.

Interfacing different object-oriented programming languages

This poster presentation illustrates the use of SOM (the IBM System Object Model) for interfacing, different object-oriented programming (OOP) languages. Our approach allows classes defined in one OOP language to be used by different (possibly non-OOP) languages—both for subclassing, and for object creation. This extends the utility of OOP class libraries and makes it possible to define “multilanguage” objects, whose supporting methods and instance variables are provided by different languages.

Multiple-view CASE support for object-oriented design (abstract)

Object-Oriented Programming (OOP) has been recognized to have great potential in producing high quality, large reusable software. However, we often find it difficult to write good C++ or Smalltalk programs. Without good program designs we will not reap the benefits of OOP. On the other hand, Object-Oriented Design (OOD) is considerably more complex than that of the traditional design disciplines such as Structured Design. Therefore, without the help of powerful CASE tools, we may not achieve the benefits of OOD and OOP. This demonstration will present TurboCASE, a multi-methodology supporting CASE tool that supports both Object-Oriented Analysis (OOA) and OOD. TurboCASE provides multiple views to help software designers create good OOD models. TurboCASE allows you to create and maintain Class Hierarchy, Class Collaboration, Class Definition, and Class Design Diagrams. The Class Hierarchy Diagram not only shows the class hierarchy, but also helps resolve how polymorphism works. The class Collaboration Diagram gives three levels of abstraction showing how objects communicate with each other. The Class Definition Diagram shows the methods and instance variables of the class, as well as providing the ability to browse the capabilities of the class inherited from the class hierarchy. The Class Design Diagram allows you to design a class similar to that of the Structured Chart with full support of the method signature specification. These diagrams are integrated through a project database, thereby providing multiple views of the software design. TurboCASE also provides intelligent help to refine the design such as abstracting the common behaviors of classes into an abstracted class. Subsystems can be designed top-down as well as bottom-up by abstracting from system components. These capabilities greatly reduce the complexities of the designs and help achieve optimal solutions.

Mass reconstruction with a neural network

A feed-forward neural network method is developed for reconstructing the invariant mass of hadronic jets appearing in a calorimeter. The approach is illustrated in W→q q , where W-bosons are produced in p p reactions at SPS collider energies. The neural network method yields results that are superior to conventional methods. This neural network application differs from the classification ones in the sense that an analog number (the mass) is computed by the network, rather than a binary decision being made. As a by-product our application clearly demonstrates the need for using “intelligent” variables in instances when the amount of training instances is limited.

Type inference for record concatenation and multiple inheritance

We show that the type inference problem for a lambda calculus with records, including a record concatenation operator, is decidable. We show that this calculus does not have principal types, but does have finite complete sets of types: that is, for any term M in the calculus, there exists an effectively generable finite set of type schemes such that every typing for M is an instance of one of the schemes in the set. We show how a simple model of object-oriented programming, including hidden instance variables and multiple inheritance, may be coded in this calculus. We conclude that type inference is decidable for object-oriented programs, even with multiple inheritance and classes as first-class values.

MELDing transactions and objects

MELD is an experimental object system under development at Columbia University. The object-oriented programming language supports classes, strong typing of instance variables, active values, multiple inheritance, and separate compilation of modular units called features that bundle together related classes and objects. These facilities were developed for an early version of MELD [3, 4], without persistence, concurrency or distribution.

Two-directional record layout for multiple inheritance

Much recent work in polymorphic programming languages allows subtyping and multiple inheritance for records. In such systems, we would like to extract a field from a record with the same efficiency as if we were not making use of subtyping and multiple inheritance. Methods currently used make field extraction 3-5 times slower, which can produce a significant overall performance slowdown. We describe a record layout algorithm that allows us to assign a fixed offset to each field name. This allows field extraction to done just as quickly as in systems that do not provide multiple inheritance. Assigning fixed offsets may require us to leave gaps in some records (and waste space). However, by placing fields at both positive and negative offsets we can drastically reduce the amount of wasted space. Finding an optimal layout is NP-hard, so we propose and analyze heuristic algorithms for producing good two-direction record layouts. In a trial run, our algorithm produced a fixed layout for the instance variables of the 563 flavors of a Lisp Flavors system; this fixed layout only wastes 6% of the total space consumed by a collection of one instance of each flavor.

An object-oriented architecture for a computer animation system

This paper describes the architecture, capabilities and implementation of The Clockworks, an object-oriented computer animation system encompassing a wide variety of modeling, image synthesis, animation, programming and simulation capabilities in a single integrated environment. The object-oriented features of The Clockworks are implemented in portable C under UNIX using a programming discipline. These features include objects with methods and instance variables, class hierarchies, inheritance, instantiation and message passing.

Proposal and Evaluation of Dynamic Object‐Oriented Programming

AbstractWe have been studying the parallel coordinated computing system composed of several AI workstations ELIS, as well as the knowledge processing on that system. From the viewpoint of the modularity and the hierarchy, an object‐oriented approach is adopted as the fundamental paradigm. In the knowledge representation on such a system, the object for representing the knowledge must be modified in a dynamical way since the knowledge always changes by itself.In this paper, such a modifiable object is called a dynamic object. In the traditional system, however, the object has been considered as static, and instance variables, for example, cannot be added or deleted dynamically during execution. The dynamic object is realized by modifying the object mechanism of TAO, which is the kernel language of ELIS.This paper proposes a dynamic object‐oriented programming based on this dynamic object, which is suited to the representation of the changing knowledge. It is indicated that from the standpoint of the dynamic knowledge representation, the dynamic object‐oriented programming is more natural and more efficient than the traditional object‐oriented programming.

Three steps to views: extending the object-oriented paradigm

At the core of any sophisticated software development and maintenance environment is a large mass of complex data. The data (the central data of the environment) is composed of smaller sets of data that can be related in complicated and often subtle ways. The user or developer of the environment will be more effective if they are able to deal with conceptual slices, or views , of the large, complex structure. This paper presents an architectural building block for object-based software environments based on the views concept. The building block allows the construction of global abstractions that describe unified behavior of large sets of objects. The basis of the architecture relies on extending the object-oriented paradigm in three steps: (1) defining multiple interfaces in object classes; (2) controlling visibility of instance variables; and (3) allowing multiple copies of an instance variable to occur within an object instance. This paper focuses on the technical aspects of the views approach.

Machine Tongues XI: Object-Oriented Software Design

ion The design technique of abstraction can be used to increase the amount of reuse within a set of classes by describing abstract classes that embody some of their shared state and/or behavior. One uses abstraction to construct a hierarchy relating several concrete classes to common abstract classes for better reuse of state and behavior. This emphasizes sharing of both state and behavior; abstract classes often implement algorithms in terms of methods that are overridden by concrete subclasses. The result of abstraction is a more horizontal hierarchy or a new protocol family. A typical abstraction example is building model graphical objects for an object-oriented drawing package. The first pass includes several concrete classes (for the different types of displayable objects). The later passes will use abstraction to reimplement these classes as a hierarchy with significant sharing among abstract and concrete classes. One would start by prototyping a wide and shallow hierarchy of DisplayItems from a collection of classes with little reuse. The first pass implements DisplayRectangle, DisplayCircle, and DisplayTriangle with common protocol but no inheritance among them and no state or behavior sharing. The second pass adds abstract class DisplayItem with position, size, and orientation instance variables and protocol for manipulation and display; concrete subclasses now inherit all their state and reuse shared protocol specification and implementations of most algorithms. The third pass refines this, adding another level of abstract modeling for line-segmentand arc-based DisplayItems; and easy extensibility is achieved. Further passes might identify Square as a special case of Rectangle and Circle as a special case of EllipticalArc. Figures 7 and 8 show three of the possible class hierarchies for DisplayItems. There are many approaches to the architecture of a framework for algorithmic composition or an algorithmic music description language. We illustrate the design as a multistep process that starts with the construction of an abstract class named EventGenerator as a subclass of EventList. Subclasses of EventGenerator should implement the message generateEvents, so we define it in the abstract class as subclassResponsibility (i.e., it is expected that subclasses will override it). The first-pass design's concrete classes are Chord (which might hold its root and its inversion), Roll (which has a single Event and can repeat it), Trill (repeat an EventList), Arpeggio (play with internote skew), Ostinato (repeat as a process), SelectorCloud (select from given pitch, amplitude, and voice sets), and PodCloud (select from given ranges). They share little state except what EventGenerator inherits by being a subclass of EventList. Several of them add instance variables to deal with their particular representations; and each implements its own generateEvents method. Shared state and behavior among EventGenerators is often not apparent until after the first implementation; and in the implementation of further subclasses, we use some of the first-pass classes as abstract intermediate classes. We try to push as much of the method implementation as possible into the abstract class EventGenerator; protocol and method implementations such as creation, accessing, and user interface can then be shared. Increased abstraction inserts abstract classes Cluster (a more general notion for chords), and Cloud (an abstract stochastic EventGenerator), and makes Trill a subclass of Roll (that repeats a collection of notes rather than just one). In Fig. 9 one can see the first-pass class diagram for EventGenerators and one of the possible abstraction-based refinements of this design. There are several trade-offs in using abstractionbased techniques. The DisplayItem and EventGenerator examples could each be used to demonstrate extremes of factorization or abstraction. Examining the construction of classes for the generation of many types of Chords, for example, one might implement a prototype that includes a class called Chord with many different methods for generating EventLists according to given rules and root