Home Demos Forum Research Guide
Viewing topic in forum 'announcements'
back to topic list

Dana v207
Dana v207 contains bug fixes, removes self-references, and includes a brand new event system along with other new primitives that avoid the need to pass self-references around.


For a long time (since version 138!) Dana has had the concept of self-references. This enabled a set of common design patterns that would otherwise be unachievable under a pure object reference/call model. However, they have always represented an awkward part of Dana's runtime adaptation system. Specifically, when an object's implementation was adapted, and references to that object which were passed out by the instantiator of the object were persistent, but self-references would become "null". This is because Dana uses a highly generalised adaptation model in which no assumptions are made about the incoming and outgoing implementation - if the incoming implementation didn't use the same secondary interfaces, or handed out self-references differently, this would represent a state disconnect across the wider system.

To complete our implementation of generalised structural runtime adaptation, in Dana v207 the concept of self-references has been removed, so that the keyword "this" no longer represents the implicit self-reference variable. Using it will now therefore produce an unknown variable error.
While this deals with the adaptation generality issue, it requires alternative solutions to support the same kinds of design patterns that self-references enable.

The event model

Dana now includes an event system which supports one of the main design patterns that self-references are used for: observer patterns. In these patterns, one object wants be notified of something happening in another object so that it can perform a related action. This is common in graphical systems to respond to user interaction events, and is also heavily used in systems-level programming to dispatch notifications of low-level events from networking to error conditions.
Dana's event system is tied into interfaces, introducing the two constructs "event sinks" and "event sources", and two new operations "sinkevent" and "emitevent".

An event source can be declared as part of an interface definition, and represents a notification handle to which listeners can be attached. An event sink can be declared in a component implementation, and is a function that gets triggered when an event of interest fires. Much more on this can be found in our new tutorial page on Dana's event model in the user guide.
As part of the event system we've also updated the native library API so that native code can fire events into Dana code (the uiplane library is a good example of this).


The second new primitive that we've introduced is the getID() function on the Object interface. This fills a gap for design patterns that the event model isn't suited for, typically seen when we need to know which object has called a given function. For this purpose we're introduced unique object identifiers, and a new standard base type function getID() so that any object's identifier can be queried, including by that object itself. These identifiers are unique in that no other live object in the Dana VM will ever have the same ID as another live object. However, these IDs do get re-cycled when objects are destroyed and so the same ID may appear for different objects over time.

Dynamic type querying with hastype

Finally, there is a subset of design patterns which require notifications from a collection to be made in a conditional way, determined by that collection. An example is a graphical system which triggers "click" notifications to graphical objects based on their position on the screen and Z-index. For this kind of pattern the above event system is cumbersome because it supports only multicast events such that all registered listeners are notified of every event. Our solution for conditional notification design patterns is therefore to use interface inheritance to indicate which objects wish to receive notifications, combined with a new hastype operator which enables runtime querying of an object to see if it supports a given sub-type. Dana's graphical system is a good example of this pattern in action, particular in the ui.Window component.

While these changes have meant that a small amount of existing source code must be refactored for use in Dana v207, we think the resulting full generality of runtime adaptation is well worth the limited disruption.

That’s all for now – happy coding :-)
by barry on 2017-08-29 15:11:59 (0 replies)

© Francis Research Ltd. 2017