Uninstalling a concrete behavior instance

[Manuel Simoni]

Is there some way to decouple a concrete instance of a behavior from its input signal (e.g. for GC or clearing caches/event-listeners), or is this in practice never needed?

[David Barbour]

On Mon, Jun 15, 2015 at 1:47 PM, Manuel Simoni <msi...@gmail.com> wrote:

Is there some way to decouple a concrete instance of a behavior from its input signal (e.g. for GC or clearing caches/event-listeners), or is this in practice never needed?

I assume that by 'concrete instance' you refer to a behavior object that contains a lot of internal cache state and perhaps contextual binding information. 

I expect you probably could externalize this state and information. There may be significant simplicity and performance advantages from doing so, e.g. similar to how we can re-align computations in entity component systems [1] to work with collections of similar behaviors. I wouldn't commit to a claim of "in practice, never needed". OTOH, this isn't something I've spent much time exploring, not even in theory. I was happy enough to get one prototype implementation working then move onto other important concerns, like easy code distribution.

My intuition is that I'd push such a separation to an RDP/language implementation/annotation layer, similar to what Jonathon Blow is attempting with the Jai language (albeit for objects and CES-like layout) [2]. I wouldn't want to be bothered very much by this low level concern as a user of RDP.

[1] https://en.wikipedia.org/wiki/Entity_component_system

[2] https://sites.google.com/site/jailanguageprimer/

[David Barbour]

On Mon, Jun 15, 2015 at 1:47 PM, Manuel Simoni <msi...@gmail.com> wrote:

Is there some way to decouple a concrete instance of a behavior from its input signal (e.g. for GC or clearing caches/event-listeners), or is this in practice never needed?

In retrospect, taking into account the title, I think I might have misunderstood your question.

Here's an answer, to a different question, which might be better aligned with what you were asking:

For a dynamic behavior, you could statically model an `BDynamic` behavior that receives two signals (a signal containing an RDP behavior, and an input signal). Upon each behavior update you would install the new behavior and uninstall the old one. We'll want to cleanly excise the old behavior, listeners, and cached state such that it can be GC'd normally. 

For this purpose, it's convenient if at least your implementation of signal values are modeled statelessly (e.g. no event-listeners directly bound to signals). In Sirea, I used stateless signals, but behaviors would still keep some state internally for cached computations.