The PLBundle player type in UniCon allows the system designer to create a collection of players, to attach significance to a group of routines and data in an architectural description of a system. The name PLBundle denotes a programing language bundle; the bundle may only contain players of types that have corresponding programming language implementations: GlobalDataDef, GlobalDataUse, RoutineCall, and RoutineDef players.
Each Member player in a PLBundle must be unique. In other words, there may not be duplicate member player definitions in a single PLBundle. Two member players are duplicates if the contents of their first fields are identical (the double-quotes are insignificant, so if one is a "string" and one an <identifier> they are identical if the names are the same - case of the letters is significant).
The same player may, however, be defined in multiple different PLBundle players in the same component. In this case, these Member player definitions refer to the same player in the source code implementation, so the specifications of all Member properties pertaining to this player must be identical inside all of the PLBundle players in which they appear.
This feature of the UniCon language allows the set of players in the source code implementation of a component to be grouped into overlapping subsets of players (i.e., via PLBundle player definitions) in the UniCon description of that component. The PLBundle player definitions can then become useful abstractions to the system designer, and a single player can be a member of more than one abstraction. For example, the C standard library contains over 700 players. A UniCon component definition corresponding to this library may export any number of PLBundle and non-PLBundle player definitions. A system designer may choose to define a PLBundle player for all input/output operations, for example, and another one for only low-level input/output operations. As you can imagine, the write routine definition might exist as a member in both of these bundles.
At least one Member property specification must be present in a UniCon definition of a PLBundle player.
The merge rule value for a given property tells the UniCon compiler what to do when a duplicate specification of that property occurs in the same property list. Usually a duplicate constitutes another property specification with the same name part. For example, any two specifications of the MaxAssocs property in the same property list, regardless of the specific contents of their respective value parts, are considered duplicates. For the Member property, a specification is not a duplicate unless the value part is equivalent to the value part of a previously specified Member property. More specifically, two Member properties are duplicates if the first field in each is the same. The case of the letters in this check is significant, but the presence or absence of double-quotes is not.
Subsequent duplicate specifications of the Member property in a single property list are reported as errors. The UniCon compiler uses the first of the duplicate Member properties it encounters.
PLAYER Sort_Bundle IS PLBundle
MEMBER (bubble; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
MEMBER (quick; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
MEMBER (merge; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
MEMBER (sort; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
MEMBER (topological; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
END Sort_Bundle
In the example above, each Member property defines a Member player in the PLBundle player. Each Member player is of type RoutineDef, and each is further specified by The PLBundle player below might be defined in the same component. It may contain some of the same Member players defined in other bundles.
PLAYER Fast_Sort_Bundle IS PLBundle
MEMBER (quick; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
MEMBER (merge; RoutineDef;
SIGNATURE ("int *"; "int *")
MINASSOCS (0))
END Fast_Sort_Bundle
Author:
Last Modified: May 12, 1996