Broadcasting

[Jason Marshall]

>
>Jason Marshall wrote:
>Context variables are used to hold the implied parameters for function
>calls.  In stack based systems, all parameters are implied.  In C 
there
>are almost no implied parameters.  Each C call has an implied name
>space, #defines and conditions.  Let us consider the following 
function
>call.
>
>	a.MyFunction(name="Kyle", age=26);
>
>In MSM code (Messaging State Machine code) we have:
>
>	GetValue(object=Primary_Key, field=a);		(1)
>	MyFunction(name="Kyle", age=26);		(2)

Ah, I see.  It looks like you and I are doing similar things.  It's 
always
annoyed me that so many OOL implementations don't treat the
'this' variable as special at all.  Aside from dynamic dispatch and a
few other niceties, they're a wolf in sheep's clothing.

How do you recover the previous context after a call to another?
A context stack?

>The GetValue function takes the variable a, a puts its value on to the
>context variable.  MyFunction expects an object to be on the context
>variable and sends it the MyFunction message.  I could expand the
>parameter listing for the MyFunction() and do the following:
>
>	MyFunction(this=a, name="Kyle", age=26);
>
>Again, I have implied that "a" is a field of the current object.
>
>	MyFunction(contextobject=this, this=a, name="Kyle", age=26);
>		 
>Now, in this example, we have removed the need for a context variable. 
>But there are many times that deep references are needed.  Here is an
>example of a single linked list.  I must look far enough ahead to be
>able to delete an object
>
>	if (this.next.next.object==removeMe){...
>
>In Object Code we write:
>	
>	CompareObject(Value1=This.next.next.object, Value2=removeMe);
>
>In MSM code the above is expanded to (assume 'a' is a local var):
>
>	Primary_Key;		//put This into context var 
>	GetValue(object=next, field=next);
>	GetValue(object=contextvar, field=object);
>	SetValue(object=Primary_Key, field=a);
>	CompareObject(value1=a, value2=removeMe);
>
>I hope that is clearer.

Yep.

>GetValue assumes that the field references are part of This.  I am 
like
>the format for GetValue now because it is very similar to a variable.  
A
>variable has  two attributes, they distinguish it uniquely from all
>other variables, and they are the object.field pair.  GetValue appears
>to requesting the value of a specific variable that has the 
object.field
>attribute pair.  But I do notice that GetValue can be streamlined into
>two functions.  Currently there are three ways to use the GetValue
>function:
>
>	GetValue(object=Primary_Key, field=<fieldname>);
>	GetValue(object=contextvar, field=<fieldname>);
>	GetValue(object=<fieldname1>, field=<fieldname2>);
>
>The last one can put in terms of the first two:
>
>	GetValue(object=Primary_Key, field=<fieldname1>);
>	GetValue(object=contextvar, field=<fieldname2>);
>
>With only two methods of using GetValue, we can make two single
>parameter functions called GetLocalValue() and GetContextValue().  
Maybe
>I will do that, but it does not resolve the context variable issue.
>
>> >Each object has a message queue, and messages can be blocking or 
non
>> >blocking. There is no semantic model to distinguish the two yet.
>> 
>> Well, let me ask you this question:  Are you set on implementing 
this
>> feature
>> at the language level, or is it sufficient to do so in your standard
>> libraries?
>
>I am not to sure I know what you mean.  I would like the semantics of
>broadcasting to be different than the semantics of unicasting.  Right
>now, logically, broadcasting is an instruction that has global scope. 
>If this instruction is a library instruction, or part of hard code 
(hard
>code is the name of source code in any language but Object Code) has
>very little distinction.  If you mean to have global broadcasting
>objects, objects that perform the work of broadcasting, I do not like
>that.  Broadcasting, to me, only has two object speakers and 
listeners;
>there is no third transport mechanism that is an implementation 
detail.

I meant the latter. 

>> That, of course, would clearly semantically differentiate the two, 
and
>> that
>> seems to be the path most languages take to achieve multicast
>> messaging.
>> Of course, the problem there is when you leave a dangling reference 
to
>> a
>> logically dead object, so maybe forcing the user to keep a clean
>> reference
>
>I do not know what you mean by logically dead object.  Do you mean
>listening to an object that will never speak?  If you are, then yes,
>that that is a problem that is not solved yet.  But if you mean an
>object that does not exist then the object that models the listening
>connection will also disappear through regular garbage collection.

By logically dead, I mean this:  
Frequently one runs into a situation where the result(s) of an action 
in the
system are contextual in nature, and may vary quite significantly based
upon that context.  In order to factor such a wide disparity in action 
down
to something more manageable, you would tend to replace one message
sink with another, rather than trying to maintain a single monolithic 
sink
which represents all possible actions.  Several of the GoF behavioral
Design Patterns are or can be used as variations on this theme, such as
the Strategy.

So let's say I'm using one strategy to handle a button click during 
business
hours, and another after business hours.  At 5:00 pm, I want to stop 
doing
the normal strategy, and start doing the new one.  How, in your system,
do I explicitly purge the business hours listener?

Without an explicit destructor, I need an external mechanism to make 
the
object stop receiving messages at a precise moment in time (5:00:00 
pm local time), to guarantee correct behavior.

>> hand, you still have the issue of needing parallel broadcast paths 
for
>> different
>> contexts of information on the same subject.  For instance, if you 
have
>> two windows open at once, in the same instance of the application, 
how
>> do
>> you prevent destructive cross-chatter?
>
>If you have two windows then you have two objects; communication to 
each
>does not create the cross-chatter. 

No, if I have two windows, I have two trees of objects, not two 
objects.
If objects in each tree plan on communicating with other objects in the 
tree, but not
in other trees (except on special occasions), more accounting is 
needed.  Or, at
the very least, a way for each tree to establish a unique message 
namespace 
is required. 

-Jason