It is tempting to compare this to various documents trying to show "how to add objects to Scheme/Haskell/etc." The solutions are rather similar...
Java Subtype Tests in Real-Time. Krzysztof Palacz and Jan Vitek.
Dynamic subtype tests are frequent operations in Java programs. Naive implementations can be costly in space and running time. The techniques that have been proposed to reduce these costs are either restricted in their ability to cope with dynamic class loading or may suffer from pathological performance degradation penalizing certain programming styles. We present R&B, a subtype test algorithm designed for time and space constrained environments such as Real-Time Java which require predictable running times, low space overheads and dynamic class loading. Our algorithm is constant-time, requires an average of 10.8 bytes per class of memory and has been shown to yield an average 2.5% speedup on a production virtual machine. The Real-Time Specification for Java requires dynamic scoped memory access checks on every reference assignment. We extend R&B to perform memory access checks in constant-time.
I don't recall this paper or this subject being discussed here.
Generalized Algebraic Data Types and Object-Oriented Programming. Andrew Kennedy and Claudio Russo. OOPSLA, October 2005, San Diego, California.
Generalized algebraic data types (GADTs) have received much attention recently in the functional programming community. They generalize the type-parameterized datatypes of ML and Haskell by permitting constructors to produce different type-instantiations of the same datatype. GADTs have a number of applications, including strongly-typed evaluators, generic pretty-printing, generic traversals and queries, and typed LR parsing. We show that existing object-oriented programming languages such as Java and C# can express GADT definitions, and a large class of GADT-manipulating programs, through the use of generics, subclassing, and virtual dispatch. However, some programs can be written only through the use of redundant run-time casts. We propose a generalization of the type constraint mechanisms of C# and Java to avoid the need for such casts, present a Visitor pattern for GADTs, and describe a switch construct as an alternative to virtual dispatch on datatypes. We formalize both extensions and prove a type soundness result.
I've been waiting for awhile for this paper to be available online.
This paper is, of course, related to the other items posted here about GADTs. The examples in the introduction might be somewhat relevant to the recent discussion about the static versus dynamic features of Java, and its type system.
Io is small, pure object oriented, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).
The paper and slides are available here.
Wiki page that shows you how to write a
aValue switch case: [matchCode1] then: [actionCode1]; case: [matchCode2] then: [actionCode2]; ... default: [otherCode].
ContextL is a CLOS extension for Context-oriented Programming. Currently, there is no documentation available, but you can find a small test case in the distribution and an introduction to ContextL's features in a first overview paper.
The paper says:
We present ContextL,a language extension for the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate such layers in the control flow of a running program. When a layer is activated, the partial definitions become part of the program until this layer is deactivated. This has the effect that the behavior of a program can be modified according to the context of its use without the need to mention such context dependencies in the affected base program. We illustrate these ideas by describing a way to a)provide different UI views on the same object while b)keeping the conceptual simplicity of OOP that objects know themselves how to behave, in this case how to display themselves. These seemingly contradictory goals can be achieved by separating out class definitions into separate layers instead of separating out the display code into different classes.
Sounds kinda like AOP to me. It intriguings, anyway.
How I got here was, two recent pieces of writing that made me think heavily were Ruby-centric: Mikael Brockmanâ€™s Continuations on the Web and Sam Rubyâ€™s Rails Confidence Builder... So I went and bought Programming Ruby ('Pickaxe' in the same sense that Programming Perl is the 'Camel book')
The conclusion of this piece is that Ruby looks like more than a fad, so LtU readers who still haven't checked it out might want to do so...
Where are the other editors, I wonder?
Juan Chen. A Typed Intermediate Language for Compiling Multiple Inheritance.
This paper presents a typed intermediate language EMI that supports multiple and virtual inheritance of classes in C++-like languages. EMI faithfully represents standard implementation strategies of object layout, "this" pointer adjustment, and dynamic dispatch. The type system is sound. Type checking is decidable. The translation from a source language to EMI preserves types. We believe that EMI is the first typed intermediate language that is expressive enough for describing implementation details of multiple and virtual inheritance of classes.
If you really must have mutiple inheritance...
Active forum topics
New forum topics