Reification (computer science)

Reification is the act of making an abstract concept or low-level implementation detail of a programming language accessible to the programmer.

For example,
* the C programming language reifies the low-level detail of memory addresses
* the Scheme programming language reifies continuations (the call stack).
* in Java programming language there exist "reifiable types", which are "types that are completely available at run time" (i.e. their information is not erased during compilation). [ [http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.7 The Java Language Specification, section 4.7] , Third Edition] In the context of object-oriented programming, reification describes the act of making a data model for a previously abstract concept. Reification allows a computer to process an abstraction as if it were any other datum. Reification is a useful technique in object-oriented languages, as encapsulating an abstract behaviour in an object makes it easier to isolate that behaviour to do unit tests.

Programs written in either C or Scheme make use of both memory addresses and continuations. However, Scheme does not reify memory addresses and C does not reify continuations (unless one counts accessing the stack by pointer arithmetic as is done when smashing the stack). Seaside for Smalltalk does both with simple extensions to Smalltalk contexts. REBOL is a case where code is data and data is code in keeping with its denotational semantics. In the case of Curl which can be viewed as a Scheme-variant, the evaluate procedure as in {evaluate {scriptoffers further reification by returning the type "any" rather as in JavaScript. Curl goes further in offering the "weak" primitive for object fields themselves to flag them for garbage collection.

When objects in Smalltalk are viewed as pointers to structs carrying pointers to functions the analogy is clear. There has been renewed interest in the explicit use of C for the implementation of Smalltalk primitives. C is also the language used to implement 3rd-generation Smalltalk in the language Io.

Unlike C or Scheme, Java now has significant projects in which it merges with languages such as Prolog, whose concept of unification has no clear counter-part in Java. When objects are used in Prolog the very notion of what is being 'reified' has to be reconsidered: when the focus shifts from 'behavior' to 'messages' the process becomes more significant, i.e., bears more meaning, than the 'thing' and a central tenet of OOP, object identity, has to be re-considered where context determines identity as much as some one pointer to the heap. The aversion to ">>become" in Smalltalk contrasts with languages that exploit transient prototype features, such as JavaScript, Self and Io or Logtalk with Prolog.

Groovy scripts for the JVM now have explicit anonymous procedures but do not yet have the continuations found in Ruby, which language itself is an alternative Smalltalk.

The Logtalk framework for Prolog offers a unique means to explore reification in the context of logic programming across most Prolog implementations. Unlike Smalltalk, Logtalk does not require the use of a metaclass; unlike Java, Logtalk does not require the use of a class; unlike JavaScript, Logtalk permits the reification of messaging, itself a feature of Smalltalk.

The use of mixins, traits and AOP requires some reconsideration of what it is that has been reified in an object and the role of object type in determining a persisting identity. In any system where a deficient 'local' object can have its role abrogated as a richer 'remote' object becomes available, reification again becomes secondary to process. The issue arises in any framework where the transient, partial or fallible status of an object is known to the program at runtime in the course of some identifiable and resumable workflow. The thesis that object identity has been preserved is sometimes a mere artifact of the use an identifier as a unique index in an underlying data store, usually an RDBMS. The recent insistence in the Ruby on Rails and in the Grails communities that an object is a row in a data table further obscures the subject by making a limitation of non-recursive SQL into a programming tenet (see tenets of ORM in the convenient marriage of OOP to SQL.)

In the early days of OOP many issues were obscured by the focus on class hierarchies and instantiating objects as instances of one fixed class. The suggestion that OOP was succeeding in modeling 'real' objects also served to obscure several key issues. The evolution of Smalltalk from 1972 to the present can be seen as a recapitulation of many of these issues. That Smalltalk evolved in isolation from Hermes and Prolog may have contributed to an over-emphasis on reification in implementations of the Actor Model.

The term reification has also been used by some in the context of formal methods to mean program refinement.

References

ee also

* Scheme (programming language)
* Curl (programming language)
* Denotational semantics
* Reference
* Dataflow
* Actor model
* Heap Pollution (computer science)
* Variable