[PEAK] References between models

[Phillip J. Eby]

At 06:26 PM 11/14/03 +0100, Radek Kanovsky wrote:

>Let me describe my problem once again:
>
>We have applications app1, app2, ... appN. These applications are
>assembled from components comp1, comp2, ... compM. There are components
>comp34, comp2, comp567, ... such that referencedType of some of their
>features points to one particular comp4.model.Contact Element:
>
>   comp34/model.py:
>     class Invoice (model.Element) :
>         class contact (model.Attribute) :
>             referencedType = 'comp4/model/Contact'
>
>   comp2/model.py:
>     class Foo (model.Element) :
>         class contact (model.Attribute) :
>             referencedType = 'comp4/model/Contact'
>   ...
>
>This works fine if i am satified with default comp4.model.Contact
>implementation. When I decide that app66 needs slightly different
>model.Contact (for example I need store also longitude/ latitude for
>contact address) I must import all components comp34, comp2, .... and
>create children of their Elements such that their referencedType for
>contact feature has value 'comp4/model/TerrestrialContact':
>
>   app66/model.py:
>
>     class Invoice (comp34.model.Invoice) :
>         class contact (model.Attribute) :
>             referencedType = 'comp4/model/TerrestrialContact'
>
>     class Foo (comp2.model.Foo) :
>         class contact (model.Attribute) :
>             referencedType = 'comp4/model/TerrestrialContact'
>     ...
>
>This probably cause cascading effect. Almost every Element in
>application should be changed now. I rely on referencedType
>values so they must be precisely defined.
>
>I don't care about other aspects of model adaptation, only
>referencedType values that points to other components cause troubles.
>If I could replace direct references 'comp4/model/Contact' with
>something indirect and configurable, I can control this references
>more smoothly from one place.

Okay, then this is a "textbook" example of what module inheritance 
(peak.config.modules) is intended for.

Look at the UML13 and UML14 packages in peak.metamodels; there is a nested 
package called 'model' in each one that is an automatically generated base 
model.  But, the parent package "inherits" from this nested package, to 
create a new package, with some alterations.

The tricky bit to use it with your intended use case, is that you need to 
reorganize so all the model components are together, e.g. instead of 
comp2.model and comp3.model, you need instead basemodel.comp1 and 
basemodel.comp2.  Then, each app can have 'thisApp.model' that inherits 
from basemodel.  Any class you wish to replace in thisApp.model, you create 
the module, and declare that it inherits from the original module under 
basemodel, and have it declare any changes to the original class(es).  You 
do not have to recode the original class, you just write that code which is 
added or changed from the original.

Now, when you import thisApp.model.comp2.Foo, its 'comp4/Contact' reference 
will point to thisApp.model.comp4.Contact, *not* 
basemodel.comp4.Contact.  This takes place automatically by way of the 
"module inheritance" mechanism.  You do not have to do anything else for it 
to work.  No registries, no lookups, no conditionals.

You are not limited to the model portion for this; note that you can also 
inherit modules containing DM's.  And, if they use relative imports (e.g. 
using a relative importString, or same-package import) of classes, they 
will also refer to the new classes when inherited.

Thus, in effect, you can cause an entire application as a whole to be 
"subclassed" with all class and function references updated.