Results 1 - 10
of
47
Ownership Types for Flexible Alias Protection
- In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA
, 1998
"... Object-oriented programming languages allow inter-object aliasing. Although necessary to construct linked data structures and networks of interacting objects, aliasing is problematic in that an aggregate object's state can change via an alias to one of its components, without the aggregate being awa ..."
Abstract
-
Cited by 278 (27 self)
- Add to MetaCart
Object-oriented programming languages allow inter-object aliasing. Although necessary to construct linked data structures and networks of interacting objects, aliasing is problematic in that an aggregate object's state can change via an alias to one of its components, without the aggregate being aware of any aliasing. Ownership types form a static type system that indicates object ownership. This provides a flexible mechanism to limit the visibility of object references and restrict access paths to objects, thus controlling a system's dynamic topology. The type system is shown to be sound, and the specific aliasing properties that a system's object graph satisfies are formulated and proven invariant for well-typed programs. Keywords Alias protection, sharing, containment, ownership, representation exposure, programming language design 1
Ownership Types for Safe Programming: Preventing Data Races and Deadlocks
, 2002
"... This paper presents a new static type system for multi-threaded programs; well-typed programs in our system are guaranteed to be free of data races and deadlocks. Our type system allows programmers to partition the locks into a fixed number of equivalence classes and specify a partial order among th ..."
Abstract
-
Cited by 261 (13 self)
- Add to MetaCart
This paper presents a new static type system for multi-threaded programs; well-typed programs in our system are guaranteed to be free of data races and deadlocks. Our type system allows programmers to partition the locks into a fixed number of equivalence classes and specify a partial order among the equivalence classes. The type checker then statically verifies that whenever a thread holds more than one lock, the thread acquires the locks in the descending order. Our system also allows...
Flexible Alias Protection
- ECOOP'98
, 1998
"... Aliasing is endemic in object oriented programming. Because an object can be modified via any alias, object oriented programs are hard to understand, maintain, and analyse. Flexible alias protection is a conceptual model of inter-object relationships which limits the visibility of changes via al ..."
Abstract
-
Cited by 192 (34 self)
- Add to MetaCart
Aliasing is endemic in object oriented programming. Because an object can be modified via any alias, object oriented programs are hard to understand, maintain, and analyse. Flexible alias protection is a conceptual model of inter-object relationships which limits the visibility of changes via aliases, allowing objects to be aliased but mitigating the undesirable effects of aliasing. Flexible alias protection can be checked statically using programmer supplied aliasing modes and imposes no runtime overhead. Using flexible alias protection, programs can incorporate mutable objects, immutable values, and updatable collections of shared objects, in a natural object oriented programming style, while avoiding the problems caused by aliasing.
Alias Annotations for Program Understanding
- In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA
, 2002
"... One of the primary challenges in building and evolving large object-oriented systems is dealing with aliasing between objects. Unexpected aliasing can lead to broken invariants, mistaken assumptions, security holes, and surprising side effects, all of which may lead to software defects and complicat ..."
Abstract
-
Cited by 179 (11 self)
- Add to MetaCart
One of the primary challenges in building and evolving large object-oriented systems is dealing with aliasing between objects. Unexpected aliasing can lead to broken invariants, mistaken assumptions, security holes, and surprising side effects, all of which may lead to software defects and complicate software evolution.
A Parameterized Type System for Race-Free Java Programs
- ACM CONFERENCE ON OBJECT-ORIENTED PROGRAMMING, SYSTEMS, LANGUAGES AND APPLICATIONS (OOPSLA), OCTOBER 2001
, 2001
"... ...programs; any well-typed program in our system is free of data races. Our type system is significantly more expressive than previous such type systems. In particular, our system lets programmers write generic code to implement a class, then create different objects of the same class that have dif ..."
Abstract
-
Cited by 170 (22 self)
- Add to MetaCart
...programs; any well-typed program in our system is free of data races. Our type system is significantly more expressive than previous such type systems. In particular, our system lets programmers write generic code to implement a class, then create different objects of the same class that have different protection mechanisms. This flexibility enables programmers to reduce the number of unnecessary synchronization operations in a program without risking data races. We also support default types which reduce the burden of writing the extra type annotations. Our experience indicates that our system provides a promising approach to make multithreaded programs more reliable and efficient.
Ownership Types for Object Encapsulation
- In Principles of Programming Languages (POPL
, 2003
"... object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the ri ..."
Abstract
-
Cited by 125 (8 self)
- Add to MetaCart
object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the right way to solve the problem is to allow objects of classes defined in the same module to have privileged access to each other's representations; we show how to do this for inner classes. This approach allows programmers to express constructs like iterators and yet supports local reasoning about the correctness of the classes, because a class and its inner classes together can be reasoned about as a module. The paper also sketches how we use our variant of ownership types to enable e#cient software upgrades in persistent object stores.
Balloon Types: Controlling Sharing of State in Data Types
- In ECOOP Proceedings
, 1997
"... . Current data abstraction mechanisms are not adequate to control sharing of state in the general case involving objects in linked structures. The pervading possibility of sharing is a source of errors and an obstacle to language implementation techniques. We present a general extension to programmi ..."
Abstract
-
Cited by 116 (1 self)
- Add to MetaCart
. Current data abstraction mechanisms are not adequate to control sharing of state in the general case involving objects in linked structures. The pervading possibility of sharing is a source of errors and an obstacle to language implementation techniques. We present a general extension to programming languages which makes the ability to share state a first class property of a data type, resolving a long-standing flaw in existing data abstraction mechanisms. Balloon types enforce a strong form of encapsulation: no state reachable (directly or transitively) by a balloon object is referenced by any external object. Syntactic simplicity is achieved by relying on a non-trivial static analysis as the checking mechanism. Balloon types are applicable in a wide range of areas such as program transformation, memory management and distributed systems. They are the key to obtaining self-contained composite objects, truly opaque data abstractions and value types---important concepts for the develo...
Ownership, Encapsulation and the Disjointness of Type and Effect
- In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA
, 2002
"... Ownership types provide a statically enforceable notion of object-level encapsulation. We extend ownership types with computational e#ects to support reasoning about objectoriented programs. The ensuing system provides both access control and e#ects reporting. Based on this type system, we codify tw ..."
Abstract
-
Cited by 108 (8 self)
- Add to MetaCart
Ownership types provide a statically enforceable notion of object-level encapsulation. We extend ownership types with computational e#ects to support reasoning about objectoriented programs. The ensuing system provides both access control and e#ects reporting. Based on this type system, we codify two formal systems for reasoning about aliasing and the disjointness of computational e#ects. The first can be used to prove that evaluation of two expressions will never lead to aliases, while the latter can be used to show the non-interference of two expressions.
Simple Ownership Types for Object Containment
, 2001
"... Containment of objects is a natural concept that has been poorly supported in object-oriented programming languages. For a predefined set of ownership contexts, this paper presents a type system that enforces certain containment relationships for run-time objects. A fixed ordering relationship is pr ..."
Abstract
-
Cited by 83 (1 self)
- Add to MetaCart
Containment of objects is a natural concept that has been poorly supported in object-oriented programming languages. For a predefined set of ownership contexts, this paper presents a type system that enforces certain containment relationships for run-time objects. A fixed ordering relationship is presumed between the owners. The formalisation of ownership types has developed from our work with flexible alias protection together with an investigation of structural properties of object graphs based on dominator trees. Our general ownership type system permits fresh ownership contexts to be created at run-time. Here we present a simplified system in which the ownership contexts are predefined. This is powerful enough to express and enforce constraints about a system's high-level structure. Our formal system is presented in an imperative variant of the object calculus. We present type preservation and soundness results. Furthermore we highlight how these type theoretic results establish a containment invariant for objects, in which access to contained objects is only permitted via their owners. In effect, the predefined ownership ordering restricts the permissible inter-object reference structure.
External uniqueness is unique enough
- In European Conference for Object-Oriented Programming (ECOOP
, 2003
"... Abstract. External uniqueness is a surprising new way to add unique references to an OOPL. The idea is that an externally unique reference is the only reference into an aggregate from outside the aggregate. Internal references which do not escape the boundary of the aggregate are innocuous and there ..."
Abstract
-
Cited by 78 (14 self)
- Add to MetaCart
Abstract. External uniqueness is a surprising new way to add unique references to an OOPL. The idea is that an externally unique reference is the only reference into an aggregate from outside the aggregate. Internal references which do not escape the boundary of the aggregate are innocuous and therefore permitted. Based on ownership types, our proposal not only overcomes an abstraction problem from which existing uniqueness proposals suffer, it also enables many examples which are inherently not unique, such as a unique reference to a set of links in a doubly-linked list, without losing the benefits of uniqueness. 1

