Jason Marshall
Sun, 02 Apr 2000 12:40:40 PDT

>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 
>are almost no implied parameters.  Each C call has an implied name
>space, #defines and conditions.  Let us consider the following 
>	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 
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 ({...
>In Object Code we write:
>	CompareObject(, 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.


>GetValue assumes that the field references are part of This.  I am 
>the format for GetValue now because it is very similar to a variable.  
>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 
>attribute pair.  But I do notice that GetValue can be streamlined into
>two functions.  Currently there are three ways to use the GetValue
>	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().  
>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 
>> >blocking. There is no semantic model to distinguish the two yet.
>> Well, let me ask you this question:  Are you set on implementing 
>> 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 
>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 
>there is no third transport mechanism that is an implementation 

I meant the latter. 

>> That, of course, would clearly semantically differentiate the two, 
>> 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 
>> 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 
to something more manageable, you would tend to replace one message
sink with another, rather than trying to maintain a single monolithic 
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 
hours, and another after business hours.  At 5:00 pm, I want to stop 
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 
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 
>> different
>> contexts of information on the same subject.  For instance, if you 
>> two windows open at once, in the same instance of the application, 
>> do
>> you prevent destructive cross-chatter?
>If you have two windows then you have two objects; communication to 
>does not create the cross-chatter. 

No, if I have two windows, I have two trees of objects, not two 
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 
is required.