Introduction to Reflection 1Jim Dowling, DSG.

Reflection and the Metaobject Protocol paradigm

by Jim Dowling

Introduction to Reflection 2Jim Dowling, DSG.

Reflection Basics• Definition: “Computational reflection is the

activity of performed by a computational system when doing computation about its own computation [1]”

• Different reflective approaches - logical, monadic• Common notion of access to a “meta” level.• Reflection allows programmer to manipulate

representations to achieve gains in performance and maintainability [2]

Introduction to Reflection 3Jim Dowling, DSG.

Some Reflection History• Computational reflection generally involves

object models– Statically typed object models (C++), dynamically

typed object models (Smalltalk)• Types categorise objects according to their

usage and behaviour• In non-reflective object models, these categories

(representations) are fixed by programming language designer

Introduction to Reflection 4Jim Dowling, DSG.

Building Meta-level ArchitecturesP ro g ra m m in g La n g u a ge T yp ing

M o n o m o rp h ictyp e sy s te m s

P o lym o rp h ictyp e sys te m s

M e ta -le ve ltyp e sys te m s

U n typ e d U n ive rsesS in g le d a ta type

Meta-level typing = Meta-type of an object characterises the typeof its object model - i.e. the way in which it is implemented [3].

Introduction to Reflection 5Jim Dowling, DSG.

1. Untyped universe

2. Monomorphic

3. Polymorphic

4. Meta-leveltypes

Introduction to Reflection 6Jim Dowling, DSG.

Application 1 Application n

Object model (C++, Smalltalk)Object subsystem (operating system, VM)

Hardware

Subsystem level

Application level

The Mile-High Systems View

Introduction to Reflection 7Jim Dowling, DSG.

Black-box Programming Model• Restricted to object

model implemented by the language

• Possibility of application mismatch - applications requirements aren’t met by underlying object subsystem

• Limited flexibility

Introduction to Reflection 8Jim Dowling, DSG.

White-box Programming Model• Language implementation

“opened up”• Features of object model

implementation can be modified by application programmer

• Structured interface for making changes

• Re-categorise objects w.r.t. their usage and behaviour.

Introduction to Reflection 9Jim Dowling, DSG.

Meta-level Architecture for OOPLs

E n g in e e rin g th e M e ta -le ve l

Extensions / Fram ew orkse.g. CORBA

M etaobject Protocolse.g. Open C++ V . 1, 2

Iguana

Reflective LanguagesE.g. Smalltalk

M eta-levelArchitecure

Introduction to Reflection 10Jim Dowling, DSG.

Meta-level features of CORBA• Extension to OOPL• Meta-level information stored in Interface

Repository, Implementation Repository• A black-box object model• ORB is not reflective• Ad-hoc additions to add reflective features,

e.g. IONA smart stubs - method_before()• Trade-offs in implementation. Dynamic

invocation 40 times slower than static [4].

Introduction to Reflection 11Jim Dowling, DSG.

Base-level

Meta-level

BLOInterface

MOPInterface

MOPs MLOs

BLOs

ApplicationProgrammer

Introduction to Reflection 12Jim Dowling, DSG.

Metaobject Protocols (MOPs)• Base-level objects (BLOs)• Meta-level Objects (MLOs)• MOP = collection of MLOs• Compile-time MOPs• Run-time MOPs• Intercessory run-time MOPs• Structural run-time MOPs• Introspective run-time MOPs• Dynamic run-time MOPs [5]

Introduction to Reflection 13Jim Dowling, DSG.

MOPs as an enabling technology• To build a meta-level architecture• White-box programming model• Behavioural Reflection• Structural Reflection• Reification of object model features

Introduction to Reflection 14Jim Dowling, DSG.

Behavioural Reflection • Allows program to modify semantics of

programming language.• Allows program to modify own code.• Ability to do this at run-time.• Techniques include polymorphism, reflective

programming languages, MOPs.• Reification of language features• Intercession - e.g. method invocation• Dynamic Adaption of object model

Introduction to Reflection 15Jim Dowling, DSG.

Structural Reflection• State and/or methods are added or deleted from

an object• Long life, stable applications• Separation of concerns between meta-level and

base-level and their implementations

Introduction to Reflection 16Jim Dowling, DSG.

Reification• Every object system contains implementations

of the object features supported by it• These object features include object creation,

message passing, state access, etc.• Reification allows these implementations to be

modified by the application programmer• Essentially making objects first-class data

types

Introduction to Reflection 17Jim Dowling, DSG.

Sample Reification• Identify object feature• Design event-based model

of object model feature to be reified

• Establish flowof control in actual object model

• Decide on which events to reify

• Implement a MOP reifying the object feature.

Introduction to Reflection 18Jim Dowling, DSG.

Iguana MOP for method invocation

Introduction to Reflection 19Jim Dowling, DSG.

Introduction to Reflection 20Jim Dowling, DSG.

History of reflection in DSG• Meta-level Architectures• Brendan Gowing - Iguana, a Meta-object

Protocol for C++• Coyote – Iguana Reflective Programming Model– Focus on building Reflective Middleware / Systems

Software

Introduction to Reflection 21Jim Dowling, DSG.

Conclusion• Reflection can make traditionally orthogonal

objectives in OO language design compatible:– Flexibility vs. Efficiency– Transparency vs.

Level of integration with subsystem• Metaobject protocols and reflection blur the

distinction between language designer and language user.

Introduction to Reflection 22Jim Dowling, DSG.

References• [1] Maes, Patttie. Concepts and Experiments in Computational

Reflection. Sigplan notices, Dec 87, OOPSLA.• [2] Friedman, Daniel P. An Exploration of Relationships

between Reflective Theories. Proceedings of Reflection ‘96.• [3] Cahill Vinny, Iguana Reflective Programming Model,

March 98, Draft.• [4] Campell Roy et. Al., Reflective ORBs, Dec. 97, ICDS 98.• [5] Gowing Brendan, PhD thesis, 1997• [6] Kiczales, Gregor, Art of the MOP, 1991, MIT Press