Next: Establish
Up: Composite Implementation
Previous: Connection

Bind

Description

The interface of a component specifies the players that the component is providing to the external world. However, in a component with a composite implementation, these players are actually implemented by players in component instantiations in the implementation. This creates a relationship, or mapping, between the players in the interface and the players in the implementation. UniCon requires the designer to make this relationship explicit. This is done with the <bind> statement. All player definitions in the interface of a component with a composite implementation must be bound to players in the implementation.

There are two forms of the <bind> statement, the simple bind, and the abstraction bind. A <simple_bind> is an association of a player in the interface with a single player of the same type in the implementation. The bind, in this case, can almost be thought of as an aliasing operation, rather than as an abstraction, since the players are of the same type. In a simple bind, no special support is required at UniCon compile time to translate the implementation mechanism of the player in the implementation into anything else since the player in the interface is of the same type.

In a simple bind, the player in the implementation must not be bound to any other player.

An <abstraction_bind> is an association of a player in the interface with a collection of players in the implementation (not necessarily having the same type as the interface player), or a single player in the implementation having a different type than that of the interface player. Abstraction binds often are necessary when the type of the player in the interface is a UniCon (or operating system supported) abstraction that is not directly supported by the programming language in the underlying implementation (e.g., a Unix stream of data, represented by the UniCon player types StreamIn and StreamOut, often implemented in a programming language by a series of calls to routines in environment-specific software libraries). In other cases, abstraction binds are necessary when a mapping from one player to another involves a type change (e.g., binding an RPCDef player in an interface to a RoutineDef player in an implementation). This type of mapping requires UniCon compile-time support to wrap up the implementation mechanism of the player in the implementation so that it becomes the implementation mechanism dictated by the type of the interface player.

The <abstraction_bind> requires the use of the MapsTo property in its property list to specify the list of players in the implementation being collectively bound to the interface player. The players in the MapsTo list must be players in component instantiations in the containing composite implementation that have not been previously bound.

NOTE: In both simple binds and abstraction binds, the implementation players must not be involved in a connection anywhere in the composite implementation, except if the player is of one of the following types:

RoutineDef
RoutineCall
GlobalDataDef
GlobalDataUse
PLBundle

Players of these types may be connected as well as bound.

Syntax

The following is the syntax for a <bind> statement:

<bind> :== 
    <simple_bind>
    | 
    <abstraction_bind>

<simple_bind> :== 
  BIND <identifier> TO <identifier>.<identifier>
    <optional_end_simple_bind_syntax>

<optional_end_simple_bind_syntax> :== 
  EMPTY
  |  <property_list>
    END <identifier>

<abstraction_bind> :== 
  BIND <identifier> TO ABSTRACTION
    <property_list>
  END <identifier>

A simple bind maps a player in the interface to only one player in the implementation. The player in the interface is specified by the single <identifier> following the keyword BIND. The player in the implementation is specified by a dot-separated pair of
<identifier>s following the word TO. The first <identifier> in this pair is the name of the component instantiation in which the player named by the second
<identifier> is defined. If there is a property list specified in a simple bind, then the END statement is required, and the <identifier> following the word END must be identical to the <identifier> following the word BIND, including the case of the letters. The only legal property for a simple bind is the Rename property, which is required if the interface player name and the name of the player in the implementation are not identical.

An abstraction bind maps a player in the interface to a collection of players in the implemenation, or a single player in the implementation having a different type. The player in the interface is specified by the <identifier> after the keyword BIND. The MapsTo property is used to specify the names of the implementation players. It is required to be in the property list; this means that the property list will never be empty for an abstraction bind and therefore the END <identifier> statement is always required. The
<identifier> in the END statement must be identical to the one after the word BIND, including the case of the letters.

In an abstraction bind, all of the players in the implementation that are being bound to the player in the interface must be specified in the MapsTo property, regardless of whether there is a single player or multiple players. Multiple specifications of the MapsTo property are allowed; UniCon interprets the collection as a single MapsTo property whose list of players is the union of the players in the lists of all of the MapsTo properties in the <bind> statement. The syntax of the value part of the MapsTo property is a semicolon-separated list of dot-separated pairs (or triples) of <identifier>s. The first
<identifier> in the pair or triple is the name of the component instantiation in which the player named by the second <identifier> is defined. If there exists a third
<identifier>, the second <identifier> must name a player of type PLBundle, and the third must name a Member player in that PLBundle.

Properties

The following property is legal in the property list of a <simple_bind>:

Rename

The Rename property has no associated value. The syntax, therefore, is simply:

RENAME

The following properties are legal in the property list of an <abstraction_bind>:

MapsTo

The syntax for a MapsTo property in an <abstraction_bind> consists of a semicolon-separated list of player names, enclosed in parentheses. A player name consists of a dot-separated pair (or triple) of <identifier>s. The first <identifier> names a component instantiation, the second names a player in the component instantiation named by the first, and the third (if present) names a Member in the PLBundle player named by the second.

MAPSTO (libc.dynamic_memory_allocation.malloc;

libc.exit,
libc.buffered_io.fgets)

Match

The syntax for a Match property in an <abstraction_bind> is either the word "by_name", optionally enclosed in double-quotes, or a comma-separated list of relations, enclosed in parentheses. A relation is a comma-separated pair of player names, enclosed in parentheses. The player name of the left-hand player in a relation represents a Member player of a PLBundle player in the interface and consists of a dot-separated pair of <identifier>s. The first <identifier> names the PLBundle player, and the second names a Member player in the PLBundle. The player name of the right-hand player in a relation represents a player in the implementation and has two or three dot-separated <identifier>s. The first
<identifier> names a component instantiation, the second names a player in the component instantiation named by the first, and the third (if present) names a Member in the PLBundle player named by the second.

MATCH (by_name)
MATCH ("by_name")
MATCH ((my_stack_adt.pop_definition,

standard_library.stack_adt.pop_definition),
(my_stack_adt.push_definition,

standard_library.stack_adt.push_definition),
(my_stack_adt.stack_init_definition,

standard_library.stack_adt.stack_init_definition),
(my_stack_adt.stack_is_empty_def,

standard_library.stack_adt.stack_is_empty_def))

Example

The following are two examples of simple binds, one with a property list and one without. Assume for the sake of the example that the input and output stream players in the statements below are of types StreamIn and StreamOut, respectively:

  BIND my_input_stream TO sort_filter.input
    RENAME
  END my_input_stream

  BIND output_stream TO sort_filter.output_stream

The following are two examples of abstraction binds. Assume for the sake of the example that the players in the left-hand sides of the binds are of type StreamIn and StreamOut respectively, and that the players in the MapsTo property are of type RoutineCall:

  BIND input TO ABSTRACTION
    MAPSTO (libc.buffered_io.fgets)
  END input

  BIND output TO ABSTRACTION
    MAPSTO (libc.buffered_io.fprintf,
      libc.buffered_io.fputc)
  END output