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;
because,
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):
(
store`mailbox`+
  customer`[ask for sale](payment);
store`agrees?
 store`[locates item];
 ok`= store`[request transfer](payment);
 ok?
   customer`pocket`+
     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
are:
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