We do not need subclasses of Rolon!

[William la Forge]

In AW4, Rolon Operations were persistent. This created problems when migrating to a new code base--a change to the operation set of a Rolon Type broke migration. Rolon Operations should depend entirely on Rolon Type. Indeed, we can have a cache of operation sets accessed by Rolon Type. And with Scala, we can have full type safety as well!

Rolon Operations should be faster in AW5 as well as being more developer-friendly. There is then really no need for subclassing Rolons, as even the eval method of a Journal Entry Rolon can be implemented as a Rolon Operation. We need only the Rolon Type.

This means that we should implement Rolon Operations as well as Rolon Types in the Kernel. Ah, have you noticed that we are having a case of feature creap? That makes it hard to meet a schedule, though the features we are adding to the Kernel should make the Core and Application Layers easier to implement. :-)

Rolon Operations will be defined as Scala Objects, which are singletons. We will use the configuration file to define sets of operations (roles) and to map a role's operation names to the operation objects via the object's class name. E.G. The Journal Entry Role's operation set contains an operation named eval, but there will obviously be more than one class for the eval operations.

Alex, I'll get this done soonest so we can have the necessary stability for you to be able to work on those system tests! Meanwhile, I'm going to have some fun learning about the Scala Type System. Type safety for Rolon Operations is not something that could have been done in Java without some awkwardness, hmm?

Bill

[William la Forge]

The code has now been reworked and all the tests are running successfully, though right now that may not be saying too much. :-)

The AW5 Kernel is now fully extensible, without allowing Rolon to be subclassed. Rather, you define new Rolon Operations and configure Rolons using a RolonType and assigning properties. This is composition based on the java.util.Properties class.

Here's a sample operation which, when added to a Rolon, turns it into a Journal Entry:

class AddEval extends _Eval {

  override def eval(

      transactionContexts:TransactionContexts,

      rolonContext:Rolon,

      targetRolon:Rolon) {

    val rolon = transactionContexts.createRolon("123","rolon")

    val be = transactionContexts.get("123")

    be.attributes.putInt("t0",-1,0)

  }

}

And here are some properties which add this operation to RolonType addJE:

  properties.put("role1.name","rolon")

  properties.put("role2.name","addJE")

  properties.put("role2.1.include","rolon")

  properties.put("role2.2.type",classOf[_Eval].getName)

  properties.put("role2.2.class",classOf[AddEval].getName)

Note that the first two lines define a base RolonType, rolon, and that addJE includes all the operations defined for RolonType rolon, which happens to be the empty set at the moment. Operations then can be inherited, indeed, multiple inheritance is supported. The Core Layer will add structural inheritance as well.

Bill