Initialisation

Model entities are always initialised with an instance of the corresponding memory bean, as per the parameter object pattern.

This is implemented in the constructor of the Identified.Private trait that sits at the root of the private API hierarchy. All subclasses delegate their only constructors to it.

Most often, we don't new() memory beans. We create them more fluently with the sentences of the Data DSL. Depending on the sentence we can create them in two modes:

• without an identifier.

  These are memory beans for new model entities, and the identifier is randomly generated:

Codelist list = codelist()....build();

• with an identifier and a change status.

We're then building a bean for an entity changeset, in which case the identifier is that of the target entity, e.g.:

Codelist list, changeset;

changeset = modify(list)...build();

Underneath the DSL, we're invoking two constructors of MIdentified, the memory bean that implements the Identified.Bean trait.

There is a third way to create memory beans that does not come into play through the DSL. Instead, it uses directly copy constructors defined on all memory beans, e.g.:

public MCodelist(Codelist.Bean other) {...}

Copy constructors come into play during versioning, which is based on cloning of memory beans. Each constructor copies from the input the state for which it is responsible, propagating the cloning process to its containers (if any), and delegating up the inheritance chain for the state that it inherits.

The process is fairly simple and uniform, except for attributes and links. Here things get slightly more complicated:

• normally the cloning process excludes the identifier. In other words, the last constructor of the chain is the no-parameter constructor of MIdentified(), which generates a new identifier for the clone. For attributes and links however, we do reuse identifiers, as this allows us to track correctly version changelogs. In this case, the last constructor of the chain is a third constructor of MIdentified`, one that takes just an identifier.

• normally, no context is required for the propagation of copy constructors along inheritance and composition chains. As we clone attributes and links, however, we need to make sure we preserve the sharing of definitions. For example, the clones of two instances of the a given definition must be instances of the clone of that definition. We do this by:

• building a context of definition clones in the copy constructor of MCodelist

• propagating the context along copy constructors until it reaches those of attributes and links

• using the definition clones available in the context whenever we're cloning its instances.