SOP (subject-oriented prog'ing)

10.3.16: adda/sop (subj'oriented prog'ing)

. exploring falcon's "(mop) (msg'oriented prog'ing),
the mop interface is this:
VMSlot: VM Interface for mop operations.
getSlot: Retreives a MOP Message slot.
subscribe: Registers a callback to a message slot.
unsubscribe(a callback): Unregisters from a slot.
assert(on a msg`slot): Creates assertion .
retract: Removes a previous assertion on a message.
getAssert: an assertion.
consume: use the currently broadcasted signal .
broadcast: to every callable item subscribed to a message.
--. this reminds me of Minsky's frames .

. ibm might have a slightly different meaning for mop;
they talk about mop being the cure for
component-fragility or
component-structure fragility
-- this is referring to the silliness that comes from
implementing oop as structs containing
pointers to function pointers .
. the example they give is:
register_sale(item, store, customer)
which a silly-oop Java call would have to express
as one of these:
item.register_sale(store, customer)
store.register_sale(item, customer)
customer.register_sale(item, store) .
"(. the essence of component-fragility.
is when calls for a service
are dependent on which of the data involved
happen to carry the implementation.
. in mop, the msg broker knows
which object carries the function .)
. that example is similar to the problem I had
with conventional understandings of oop:
for binary operations like addition,
conventional oop was doing this: x.+(y)
when what was really going on
was this:
num's-add( destination.num, x.num, y.num)
where num is a supertype or
class of types sharing an interface:
{real, integer, complex, rational, ...}

. in the example of registering a sale,
there are 2 objects: {store, customer}
it doesn't need to involve the item;
an object interface is primarily needed
only for controlling modifications
not mere accesses .
[3.29: or, a good reason in this case is that
none of the operations on an item are binary .
... still no clarity during double-check ... .
. after a sale,
the store has more money and less item,
while the customer has the opposite .
. in this transaction,
the item was just a constant id number .
. the abstraction of the transaction
is this:
    [register a sale](store, customer):
customer`[ask for sale](payment);
store`[locates item];
ok`= store`[request transfer](payment);
store`[receipt and item] .
. so, registering a sale is simply
a classic example of the need to
mix oop with procedural programming;
ie, it's actor transaction directing,
where the purpose is to orchestrate objects .

. perhaps ibm's mop is merely saying the same:
that there really is no place
for a system where "(everything is an object) .

ibm's Message Central project
. at ibm's Message Central project
the goal is to enable widespread use of
component-based software,
[3.29: the way hardware is engineered? ]

. ibm`mop tools include:
SAGE (Scalable [inter-component] Adapter GEnerator),
and the
Continuum programming language
[translates oop'ish designs into]
reconnectable components.
. sage is based on tools for
sop (subj-oriented programming),
which is a type of aop (aspect-oriented prog'ing) ...
. ibm`Hyperslices are generalizations of subjects from sop .

sop at ccs.neu.edu:
"(Subject-oriented programming focuses on
operations as join points
(vs statement-level join points)
and functional aspects.
Some examples of functional aspects being
best described in terms of operation join points
Persistence, error detection and handling,
fault tolerance, logging, tracing
and metrics-gathering.)
. sop was first defined here: (pdf)
ibm` Harrison & Ossher`
Subject-oriented programming: a critique of pure objects
Proceedings of the Conference on
oop, Systems, Languages, and Applications, 1993

. here we've seen that sop's gist is basically
the same as ibm's mop?
[3.29: or at least ibm`mop's motivation
is the same as sop's .]

Subject-oriented design: towards improved
alignment of requirements, design, and code
Conference on
oop Systems Languages and Applications
Proceedings of the 14th ACM SIGPLAN conference on
oop, systems, languages, and applications 1999