[Swarm-Modelling] lifecycle requirements

[glen e. p. ropella]

To make this discussion more appropriate for the modeling list, I'd
prefer to talk about what ABMers _need_ and where Swarm (or any other
tool) meets or fails to meet those needs.

In that context, what interfaces need to be there?  And what would a
complete interface for any given capsule of functionality entail?

Defobj is important to me as a concept but not as it's currently
available or implemented in Swarm.  I think it should be less oriented
toward a "pragma", telling the compiler or run-time how to build a class
and more toward an explicit expression of the model.  Originally, I
thought of defobj as a kind of reflection, which allows code to explore
an object or class and operate on what it finds.  But, I'd prefer it to
be more like a data-driven programming language, like a set of filters
that you arrange to make progressive modifications to an agent.

An (perhaps bad) analogy would be to the life stages of a human:
conception, gestation, birth, pruning, puberty, menopause, death, and
any others I've left out.  The object at the beginning need not retain
any of the same constituents as it had at the beginning.  Now, for a
short and simple evolution the typical approach is to use if-then
branches and completely specify the entire hyperspace of _state_ the
object(s) will need for the whole life cycle.  For more complex
evolution, a "switcheroo" (as Manor used to call it) occurs so that the
identifier at one stage is completely different than the id at another
stage.  And this can be managed with protocols and dynamic binding.

But, rather than have to explicitly characterize the entire hyperspace
_or_ pre-specify and name interfaces to which the object will sometimes
adhere, I'd rather just build a set of object operators, submit the
object to the operator (or have the object submit itself), and out pops
the new object without the result having to match any pre-determined _type_.

This implies that at each attempted application of an operator, the
object would have to be explored and if it matched a (possibly dynamic)
template, then the operation goes through.  If not, the operation bails,
possibly leading to some other branch of logic.

Thinking about it this way leads to something more like Sun's JINI API.

My question to the list is:  What, if any, modeling level requirements
do you think are important and does the outline I provide above target it?

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
There is all the difference in the world between treating people equally
and attempting to make them equal. -- F.A. Hayek