listener capability

6.10:
. in the listener model, any time an obj' modifies itself,
this update is supposed to be published to any registered listeners .
. listener capability is like a file attribute:
along with the predicates of what the owner is permitted:
readable, writable, or exe'able
there is also:
publishable .

[7.5: . the system should be helping type-mgt to impl' this;
just as it does for policing parameter and access modes:
"{ constant, in, out, inout} . ]
. when an object has the attribute"publishable,
then the system can find
any place where writing operations have been applied,
and replace that writing call
with the same call followed by a publish .

. registered listeners are then given an email with a link to the obj;
[7.5: ie, listening is modeled as a asynchronous communication
between concurrent processes;
any time a listener requests to know about changes to an object,
it is identifying that object by an url,
and any mailed reports of updates will be using that same url .
however,
there is another model: intra-process listening,
as when the model-view-controler pattern is used,
and the view.obj needs to be kept in sync with the model.obj .
. in this case, the subscriber doesn't simply want receipt of changes,
rather, it wants the compiler to bundle any writing call
with additional calls that use the author's value
in a function of the subscribers choosing;
so, when the model-view-controler pattern is used,
the code: Listener`listenTo(Author)
would be translated to:
compiler`(for each write-call to Author:
append Listener`= image Author`value
)
]

discussion:

. it's asking the class"mem to actually implement the writes as
what its own class really does
. during an object operation it is describing
how to translate its operation on a value
into the way the class"mem should actually write the value change to the memory .
. so then the type-mgt itself doesn't need to support listening,
it's a service of class"mem:
given an obj', it will keep track of that obj for you,
as every time it gets a call to make a write,
it checks if that chunk has a listener bit set,
and if so, then it refers to that chunk's obj's entry in the publishings directory,
which tells who's listening to the obj .

. a complication to this theory of this system
is that
it is type-mgt that is assigning memory to an object;
and, this can also mean dynamically changing memory,
either as the size changes,
or as a way of efficiently dealing with assignments
without having to copy the value,
it just gives it the new block,
and recycles its current block to some other use .

. in short,
type-mgt virtually has to assist in supporting listeners,
since only type-mgt and not mem-mgt is aware of dynamic obj-mem associations,
yet its clients are asking mem to target obj's rather than mem chunks .

. so all the classes that adda comes with will support listening,
and user defined classes can optionally support it .

. another theory is that
adda be smart eno to morph the source,
so that if listening is needed then
dynamic code injection is providing this capability .

. in sum,
the main req's are that things should be kept simple for new class designers,
and still provide the listener service .