Two object categories:
Variable state objects (or services) and immutable value objects (or structures)

Problem statement

State objects

The essence of a state object is that new values may be assigned to its member variables again and again, and that two state objects are considered to be "equal" if they are identical, i.e., the same object. Copying/cloning a state object will normally contradict their "uniqueness semantics".

Value objects

The essence of a value object is that its immediate and also its recursive constituent objects cannot be replaced by other objects any more as soon as the object leaves the "new" construct (which creates new objects of some specifiable class). In this sense, the object is frozen after creation.

Furthermore, comparing two value objects amounts to a recursive comparison of all their constituents.

If you don't want to completely freeze an entire object, including all its nested constituents, then you can specifically declare individual member objects of a Lava class to be "constant". Then only these members are protected against replacement by other objects.

Since Lava 0.9.1 we have modified the category notion in the following way:

1. In variable declarations the category of a variable is now attached directly to the variable and no longer to its class.
2. The category isn't a property of the objects themselves any longer: objects don't know their category, but the object category of a variable specifies a way how objects are treated when accessed through that variable. LavaPE makes sure by its comprehensive static checks that categories of variables are used consistently. So, for instance, the value of an expression that has been declared to deliver a value object cannot be assigned to a state variable.
3. The "immutable"/"value object" category is now inherited by all immediate and also all recursive constituents. In other words: "Immutable" is now applied to the entire object including all its nested constituents, even if the latter are declared to be state variables (but not including its acquaintances, which are considered to be independent objects in Lava).

Declaration of state and value objects

Lava objects can be referenced only indirectly as values of Lava variables: Lava variables point to Lava objects, they are always of "reference type" as you would say in Eiffel or Java. Several variables may point to the same object. The data type of a Lava variable v is described by a Lava class, say A. The value of a Lava variable may be any object of class A (or a class derived from A).

The same Lava class may be used to declare variables of either category : state or value. The category is specified as part of Lava variable declarations. If a variable is declared to be of the "state object" category then a "~" (tilde) precedes the name of the variable in the Lava declaration tree and in the quantifiers/declare constructs where they are declared in executable code.

A variable may be

• a member variable of a class or implementation,
• or an input/output parameter of a member function of a class or of an initiator (~ kind of main program of an application or thread),
• or a local variable that is declared within an exec (= executable body of a function or initiator) or invariant (which is executed on completion of a new object and after every method invocation on the object).

See also: Stages in the life of Lava objects (sample)

Component objects

are special state objects that are dynamically created or static "inhabitants" of "components". Components are dynamically loadable software modules in which component objects may be activated/created that can communicate with other component objects over well-defined language-independent function-call interfaces.

See also: Lava as a component integration language

Persistent, particularly database objects

Persistent objects are component objects that can be "attached" by other components. It is expected that they exist already at this time, although they may exist in a deactivated state and thus must be activated before they are attached. In Lava, databases are treated as special persistent objects.

See also:

Stages in the life of Lava objects (sample)