records generated from UBF

[Ulf Wiger]

On Tue, 15 Apr 2003, Vlad Dumitrescu wrote:

>Hi,
>
>Just a quick and silly question: for me the most
>interesting part of UBF is the contract checker; it could
>also be used with normal Erlang messages, not only with UBF
>- the question is: why not do it like this?
>
>I think that it would be very useful (and also super-cool)
>if such a contract-checker could be introduced between any
>two processes, transparently.

The contract checker consists of two parts (I think -- I
haven't really studied that part of the code in depth):

- A middle-man process that keeps track of the server's
  state and checks incoming and outgoing messages. This
  process calls known helper functions in the server's
  callback module in order to check the message.

- A parse transform that reads the contract and inserts
  said helper functions in the server callback module.
  The helper functions are:
  + contract_name()     -> string()
  + contract_states()   -> [atom()]
  + contract_types()    -> [atom()]
  + contract_state(S)   -> [{input,type(),type()}
                           | {event,type()}]
  + contract_anystate() -> [type()]
  + contract_type(Type) -> type()

Thus, the contract checker depends on UBF(B), the type
definitions, and UBF(C), the state machine specification,
but not on UBF(A), the encode/decode scheme.

One could most likely design a UBFish gen_server that
implements the UBF contract checking, but skips the
encode/decode part.

/Uffe

-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes