Broadcasting

[Kyle Lahnakoski]

Jason Marshall wrote:
 
> How do you recover the previous context after a call to another?
> A context stack?

Any previous contexts are stored explicitly in the variables of the
frame of the executing function instance.  If a large, possibly
infinite, amount of previous contexts must be stored then there must be
explicit use of storage structures.  I am lucky because I use set
operations instead of loops.  Any particular, non atomic, function will
only have O(1) instructions executed.


> 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?

Broadcasting/listening is modeled with objects.  Explicitly a broadcast
object looks as follows:

	BroadCast_Class{  //define the class name
		Object_Class from;
		Object_Class to;
	}

By creating objects with specific from/to attribute values listeners can
be added.    Deleting objects with certain from/to attribute values
removes the listener.  For instance, in a piece of code that has already
been triggered by the 5:00 tick we have (this is only rough)
	...
	Object_Class from;	//the from object
	Object_Class oldto;	//the old listener to remove
	Object_Class newto;	//the new listener to add

	//remove the old listener
	//filter on the from and to column
	Filter filter1=Filter.NewInstance();
		filter.field=Broadcast_Class__from;	
		filter.value=from;
	Filter filter2=Filter.NewInstance();
		filter.field=Broadcast_Class__to;	
		filter.value=oldto;
	//build the query that will use the filters and delete all
	//matching objects
	Query query=Query.NewInstance();
		query.setFunction("a.delete()");
		query.setTable(Broadcast_Table);
		query.addFilter(filter1);
		query.addFilter(filter2);
	query.execute();
	
	//add the new one
	Broadcast_Class broadcast=Broadcast_Class.Newinstance();
		broadcast.from=from;
		broadcast.to=newto;

	...

I have tried my best to make sure that every aspect is characterized by
an attribute somewhere.



> 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.

I hope this answers your question:  Every object has a unique ID, called
the primary key.



-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com