Below are my notes for subject-oriented programming - an enhancement to the object-oriented programming paradigm. Some Pattern-oriented programming concepts are also mentioned.
Pattern-oreiented : write syntax patterns first then write the arguments (which are subjects, objects, literal expressions or expressions of subjects/objects/literal expressions)
Subjects
Subjects are references to objects
Objects have two kinds of properties :
1) Content property: an object contained in this parent object
-- {implemented via embedding or object pointer(delete rule applies)}
-- a collection is a single object not a subject or a relationship
2) Reference property: to an object outside this object container (relationship)
-- ??? to-many relationships are implemented as a set collection (embedded/pointer object) of references (subject)
?? not sure how to implement relationships
?? what about mingle style elements where an object can be a member of may trees
- This means you can't hard code the relationships (object or subject) in the object because there are an unknown number of them at runtime.
- We need an "N-ary" set of "member contexts".
Properties
name : face reference ( class )
name : face ( class )
name : face
name [ structure specifier ] : face reference ( class )
name [ structure specifier ] : face ( class )
name [ structure specifier ] : face
-- all collections for properties are content
-- all properties have a "collection", the default being the "optional" collection meaning 0 or one
Relationships
-- are implemented using properties
the property scope must be a reference
to-many relationships have a structure with multiplicity. e.g. [0...], [tree], [set]
Things in the runtime environment:
Server
- a server is defined by a set of related services
- at least one service should have side effects on the repository, otherwise its just a read-only server
Services
semantics :
- when a service is invoked from outside the server a new and unique service instance is created
- a service is defined by a single routine (this top-level routine starts the call heirarchy)
- service instances contain routine calls (like a call stack)
- types of routines : blocks (in-line), patterns (procedure/function)
- the execution of a block, procedure or function creates a new routine call
implementation :
- a service instance may implemented by a thread
- threads may be reused for many service instances
- every routine call has exactly one thread (the thread of the parent service instance)
Routines
- routines have local data (on the thread call stack) called "subjects" which is the way they access objects in the repository
- routines define formal arguments' unique names. The complete actual arguments forms a map <String --> Primitive/Object/Facade>
- routines define formal arguments' types as faces. Any class that exports that face or a sub-face is compatible
- routines define actual arguments (in a call) as either :
1) subjects (with a compatible facade) or
2) objects (with a compatible class face)
- routines have exactly one main block - the block should perform the requested service and have side effects on some argumants
Blocks
semantics :
- like an in-lined call without any arguments
- sequence of statements with local variables (thread state) and local subjects (repository state)
- blocks inherit variables and subjects from its parent routine (either a block, a call or the main routine of the service instance)
- routine actual arguments are inherited down to all contained blocks
implementation :
- blocks could be implemented as special no-arg/no-return routines and then at code generation time all routines (patterns or blocks)
could be either made into calls or in-lined depending on performance optimisations and settings
Patterns
- patterns are defined by a single routine and a syntax that contains formal parameters
- calls other routines by specifying a sentence of the pre-defined syntax
- actual arguments are interspersed in the syntactical sentence
(e.g. " add x to count ", " count += x ", new Node with value green ")
Clusters
- grouping of class heirarchies / face heirarchies / routines and a call delegation table
- clusters can be organised into a heirarchy (like eiffel)
- referencing artifacts in external clusters is done in a separate aspect file so source code is not contaminated (eiffel model)
Call Delegation Table
- a list of patterns (overloaded by type) mapped to a routine
- used to determine which routine to call for a given pattern at compile time.
- note all routine arguments are statically typed by face so the delegation table will be deterministic.
Subjects
semantics:
- like an object but the set of routines and properties are restricted according to the face of the subject
- in addition to the object features there is a contextual state (routine call scope) associated with this subject as defined by the face
- like a connection between a routine call's scope and an object and the connection can have its own state.
implementation :
- a reference to an object in the repository plus an instance of a face (facade) compatible with the class of the object.
- when patterns that specify local subject names are delegated to a routine the facades are passed as the actual argument
- when patterns that specify local objects (still in routine scope) are delegated to a routine a facade is created then passed as the actual argument
- one static and four local variables (or fields of a structure) :
1) subject_objcls references the class of the object (set when the object type is known - e.g. subject is a reference to an element of an ADT so obj may be null but type is known)
2) STATIC subject_typ references the face (used to check compatibility of object class and then determine the facade class after the object class is set)
3) subject_fcdcls references the facade class (used to instanciate the facade)
4) subject_fcd references the facade (internally can reference the face, object class and object)
5) subject_obj references the object
- when an object is assigned to a subject a new facade is created and the old is freed
- when a subject is assigned to a subject the references are just copied (provided the facade class is compatible with this subject's type)
- when null is assigned to a subject all the references (except type) are set to null also
Faces
implementation :
- code generation : generate a java interface and/or class for each face.
- code optimisation : if you know what face (facade class) the subject will always have then you can generate in-line code in the subject's routine to perform all the operations on this subject.
(then there is no need to instanciate a facade at all for that subject)
- routines become java methods where the "subject" arguments are typed by the java interfaces/classes corresponding to the face.
- actual arguments ("Facades") will be instances of these classes
Objects
- instance of a class
- may live in one of two life-cycle environments :
1) the local scope of a routine (i.e. thread stack)
2) the repository (e.g. java heap space)
- local objects are memory only
- repository objects have the option to be persistent (depends on repository persistence mechanisms)
- local objects optionally have facade too