Symbolic Object-Oriented Programming

Symbolic object-oriented programming rests on a single change to what an object is: it keeps the arguments it was constructed from. A program built out of such objects is still a program you run, but it is also a structure your code can read, rewrite, compare, and search over.

PyGX provides two capabilities on that foundation, answering two different questions:

• the Symbolic Object Model (SOM) — what a program is made of, and how to manipulate it. This is dynamic representation, and it is what most of this section covers.
• Symbolic Detour (SD) — how a program is interpreted, letting the same symbols resolve to different classes at runtime. This is dynamic interpretation, and it works even on code you cannot modify.

The two are independent: SD does not require your classes to be symbolic.

Symbolic Object Model

The Symbolic Object Model (SOM) is the core of the paradigm, and is what gives an object its dynamic representation. SOM stores initialization arguments as symbolic attributes and allows inspection and manipulation of them. It also includes a symbolic schema system for validation and a messaging system for handling mutations. Symbolic placeholders are also supported for representing unknown program parts.

• Definition
• Types
• Operations
• Events
• Validation
• Placeholding

Symbolic Detour

Symbolic Detour (SD) is independent of the SOM, allowing users to alter class mapping without modifying the source code that instantiates the classes. This is particularly useful when the source code cannot be symbolized for various reasons. SD complements SOM.

• Symbolic Detour