You are here: Home V2 Software Software More ... Memops Code Generation Strategy Documents Reserved Names

Reserved Names

How to handle model names that clash with language or implementation names. IMPLEMENTED Rasmus Fogh 2007


Names in the data model can be chosen freely, but some names might be illegal or clash in some languages or implementations.

Fortunately the element names mostly do not appear in contexts where they cause problems. There are some problem cases. Model names could clash with

  1. Names of autogenerated attributes or functions.
  2. Names of Implementation attributes and functions, like (in Python) getByKey, notifiers, metaclass, or keyPath.
  3. Language reserved words in the parameter definitions for init and new, in the subtypes that take explicit parameters rather than a map.
  4. XML constraints. XML element names starting with 'xml' in any combination of upper and lower case are illegal.
  5. Python keywords through the Python obj.attribute syntax. You cannot say 'obj.attr=value' in Python, if 'attr' is a Python keyword.



Proposed solutions, point by point

1) These clashes will be discovered when we run the appropriate ModelAdapt. We will have to accept that some illegalities can not be discovered before then.

2) We should adopt the convention that public attributes and functions should be put in MemopsBaseClass, so name clashes can be detected. If they are not general enough to fit into the UML they can be put in by ModelAdapt.

We should further reserve names that start with an underscore ('_') for implementation functions, making such names illegal in the UML. In practice this means that only implicit ModelElements can have a name starting with underscore.

3) in practice only affects internal names in the generated code.
4) similarly affects only XML tag names
5) is harder, as it affects the attribute names the public sees and uses.

For all these cases we should rename the offending variables through a namemapping facility in ModelAdapt - it is there already, but is currently used only for function variables. It is regrettable in case 5), but we can not guarantee to comply with all now and future Python keywords.

In practice I would suggest adding an initial underscore as the standard renaming. This can be done automatically by the relevant ModelAdapt. As an implementation matter, we should add a MetaModelElement.usename attribute to hold the alternative name. The attribute should default to the normal name. It should be freely changeable, and should be reset to zero by package.reset(). We can then keep the constraint that names coming from the UML may not start in underscore.


As of May 2007 all functions with normal names have been removed from memops.general.Implementation. Moved functions have been put either in the various ModelAdapt scripts, or in the model itself. Only python-specific implementation functions like __repr__, __cmp__ etc. have been retained.

The rule on the use of underscores is enforced in the MetaModel.

The 'usename' attribute is in the MetaModel, to store the name that should be used instead of the actual name in any given context. It is not uased in the generation code, though. NBNB TBD.