rmTypeName in CObject (CComplexObject) not in grammar


But there is a typeId (is that the same?)
Also is the case that typeId in the grammar represents a List of typeId's (string),a nd there is no room for such a list in the definition of CComplexObject (although, I did not find anything like that)




Thomas Beale
January 14, 2016, 11:06 AM

There is no general guarantee that a syntax will follow exactly an object model that is the output of a parser. For example, 'inheritance' does not typically operate in the same way at the syntax level as in an object model. Consider the rules

c_complex_object: type_id '[' ( ROOT_ID_CODE | ID_CODE ) ']' c_occurrences? ( SYM_MATCHES '{' c_attribute_def+ '}' )? ;
c_archetype_root: SYM_USE_ARCHETYPE type_id '[' ID_CODE ',' archetype_ref ']' c_occurrences? ;
c_complex_object_proxy: SYM_USE_NODE type_id '[' ID_CODE ']' c_occurrences? adl_path ;

They all have a 'type_id' in them; where 'type_id' is a rule corresponding to type names. In the AOM, this happens to map to the property C_OBJECT.rm_type_name, but that could have been different. We would not put 'rm_type_id' in the parser rules, because it's just a type id, not specific to some model. It's only in the AOM where that makes sense. (Well, we could do it by adding in another substitution rule, but it seems a pointless waste...)

Consider that in the parser implementation you will instantiate concrete classes like CComplexObject etc, not CObject, which cannot be instantiated. CObject is just a modelling artefact of the AOM - it could be refactored in a different way, so that CObject was not there, or differently named, but with the same results for CComplexObject etc, and no effect at all on the syntax.

Bert Verhees
January 15, 2016, 8:49 AM

Thanks, I can live with this answer. Since I use the AOM as defined now, I need to map it to rm_type_name, as I thought.


Bert Verhees




Affects versions