Broadcasting

[Jason Marshall]

><preamble>
>
>One thing that I have noticed about myself is that I will speak as if 
I
>am talking of implementation.  I am not.  I usually talk in terms of 
an
>apparent model.  This model, technically, has nothing to do with
>implementation.  

Interface frequently suggests a default implementation, but rarely
dictates it.

>Function instances (also called Messaging State Machines) are objects
>that are executable.  In C a function instance is the stack space a
>function would use and the space taken for temporary variables.  It
>would not include the executable code, that is a "function"  Please 
see
>http://www.arcavia.com/rd/dbc-html/Function.html for a better
>explanation.

You've just described a stack frame, or an activation record, yes?

>Function instances, in DBOS, have a single context variable.  A 
context
>variable is much like a stack except it has a maximum and minimum size
>of one.  I can not seem to get rid of the context variable.  This does
>not bother me anymore.

Care to elaborate here?

>Broadcasting:  What is it?  How should it be modeled?
>
>Consider yourself an object.  Currently, to get work done, you send
>messages to other objects.  Semantically, I chose:
>
>	destination Object.MyMessage(Name="Kyle", Age=26);

As I recall, Smalltalk also makes the distinction of treating all 
method 
calls as messages.  This makes some sense when you consider that
the language is dynamically typed, and so you can add or delete 
message handlers (methods/interfaces) at runtime.  I'm not aware of
the multicast mechanism, but my knowledge of the language is limited. 

>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?
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
to objects they want to keep around (instead of relying on an event 
queue
to keep your object live), making things a bit more explicit.  On the 
other
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?

-Jason