Map
Index
Random
Help
Topics
th

Topic: type reflection and introspection

topics > computer science > programming > Group: object-oriented programming



Group:
object-oriented programming
Group:
type checking

Topic:
binding of names to objects
Topic:
casting a variable to a different type
Topic:
compressed code
Topic:
dynamic code modification
Topic:
dynamic vs. static data type
Topic:
early vs. late binding
Topic:
initialization of data
Topic:
interpreter
Topic:
just-in-time compilation
Topic:
object-oriented prototypes
Topic:
opaque and partially-opaque data types
Topic:
open systems
Topic:
property sheets for objects
Topic:
safety, liveness, and system properties
Topic:
self-identifying data structures
Topic:
self reference
Topic:
source-rich system
Topic:
symbol table
Topic:
type reflection and introspection
Topic:
type variable
Topic:
understanding systems
Topic:
words defined by words

Summary

Type reflection and introspection provide type information at run-time. For example, code can determine the class of an object, its available methods, and the types of its operands. The code may use this information to invoke methods or customize its behavior.

Type information is called metadata. At compile-time, the symbol table stores this information. Historically, arrays included size information for run-time bounds checking, and variant types could include a type tag. With object-oriented programming, objects usually contain a pointer to type information and the method dispatch table. Code can convert types or test for type tokens. Byte-code systems such as Java and C# often include full-type information. They may allow the creation of new types or additional methods.

Mirrors separate type information from the object itself. A property editor provides read and write access to objects and classes. (cbb 7/06)

Subtopic: reflective systems up

Quote: a reflective system is causally connected to itself by a self-representation; can modify itself [»maesP12_1987]
Quote: almost all reflective systems use a meta-circular interpreter that is defined by the language itself; e.g., LISP's eval [»maesP12_1987]
Quote: reflection is best for design time use by component-based application builder tools [»blocJ_2001]

Subtopic: reflective API up

Quote: codesign a language and its reflective API; keep both simple [»bracG10_2004]
Quote: reflection should encapsulate an implementation, that is separate from the base-level functionality, while corresponding to the base language; mirrors built to these principles, unlike other reflective architectures [»bracG10_2004]
Quote: reflection can allow a program to examine its own structure, modify the structure, execute dynamically-generated code, and modify the language's semantics [»bracG10_2004]

Subtopic: metadata, RTTI up

Quote: PL.8 generated type metadata for every external variable; used for link edit and load-time type checking [»auslM6_1982]
Quote: use display mechanism for run-time access to extended type descriptors; construct at compile time [»coheNH10_1991]
Quote: C++ run-time type mechanism: 'dynamic_cast' from a base class, an explicit 'typeid', and implementation 'type_info' [»stroB_1994]
Quote: put details in the metadata, abstractions into code; think declaratively for ease of change at the last moment [»huntA_2000]
Quote: store metadata for library data structures in a parallel data structure; e.g., another linked list to mirror a linked list [»necuGC5_2005]

Subtopic: mirror up

Quote: use mirrors to avoid problems with Java reflection when debugging remote classes; the Java Debug Interface (JDI) mirrors the remote, virtual machine; e.g., loaded classes, threads, metadata, and values [»bracG10_2004]
Quote: Self introduced mirrors; i.e., a dictionary of slot names, or a "slot object" of a slot's properties and value [»bracG10_2004]

Subtopic: property editor up

Quote: SUIT property editor displays object, class and global property lists; drag-and-drop; makes it easy to learn state inheritance [»pausR10_1992]
Quote: SUIT's property editor is the same for all objects; easy to learn and immediately available [»pausR10_1992]

Subtopic: examples up

Quote: Ruby is a pure, untyped, object-oriented language with metaclasses, iterators, closures, reflection, run-time extension, dynamic loading, marshalling, threads, exceptions, garbage collection [»thomD1_2001]
Quote: CLR reflection allows runtime type creation, queries, and method invocation [»hamiJ2_2003]

Subtopic: compatibility up

Quote: hot swap modules need to change types while preserving type safety; use reflective mechanism with programmer-defined version adapters [»duggD9_2001]

Subtopic: type tests up

Quote: Oberon has type tests and type guards for testing extended types given a base type [»wirtN7_1988]
Quote: run-time type information and physical subtyping identify 99% of program casts without usng WILD pointers [»necuGC5_2005]
Quote: runtime type verification by predicate ISTYPE, assertion NARROW, or SELECT of type cases
Quote: Oberon types include a pointer to the base type's descriptor; name equivalence of types, not structural equivalence; for type tests/guards [»wirtN9_1989]
Quote: before using an object as a different class, need to check for the class [»palmJ5_1973, OK]
Quote: operations defined on the type 'type' to return all instances, legal operations, and legal properties [»zdonSB11_1986]
QuoteRef: bekiH_1971 ;;150 n::= v checks v and n for mode conformity before replacement
QuoteRef: ledgHF9_1971 ;;134 types can be associated with value (needs dynamic type checking)

Subtopic: problems with reflection up

Quote: avoid reflection; no compile-time type checking, syntax is clumsy and verbose, performance is slow [»blocJ_2001]
Quote: use reflection to create objects and use their interface or superclass for access
[»blocJ_2001]

Related Topics up

Group: object-oriented programming   (26 topics, 822 quotes)
Group: type checking   (12 topics, 392 quotes)

Topic: binding of names to objects (19 items)
Topic: casting a variable to a different type (7 items)
Topic: compressed code (17 items)
Topic: dynamic code modification (15 items)
Topic: dynamic vs. static data type (24 items)
Topic: early vs. late binding (15 items)
Topic: initialization of data (45 items)
Topic: interpreter (59 items)
Topic: just-in-time compilation (20 items)
Topic: object-oriented prototypes (39 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: open systems (33 items)
Topic: property sheets for objects (29 items)
Topic: safety, liveness, and system properties (22 items)
Topic: self-identifying data structures (18 items)
Topic: self reference (27 items)
Topic: source-rich system (27 items)
Topic: symbol table (4 items)
Topic: type reflection and introspection (28 items)
Topic: type variable (5 items)
Topic: understanding systems (48 items)
Topic: words defined by words
(25 items)


Updated barberCB 5/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.