Repository navigation
Wrong code generated for enums #34
Description
See pyecore/pyecore#126 (comment)
Quoting from there, for enums,
pyecoregen generates the wrong code:
for classif in otherClassifiers: eClassifiers[classif.name] = classif classif.ePackage = eClass for classif in eClassifiers.values(): eClass.eClassifiers.append(classif.eClass)What happens is that, initially,
eClassifiersis empty. Then, first, enums are added toeClassifiers, and then theeClassof each object ineClassifiersis added to theEPackage(that for some reason is calledeClass). So we have theEEnumclass added to the package we're defining! And, of course, it gets removed from the Ecore package, becauseeClassifiersis a containment relationship. I don't know the purpose of the secondforloop, maybe it was to handle custom metaclasses or stuff like that, but it should filter the classes that it puts intoeClass, or be removed altogether if it's not necessary.
Activity
aranega commentedon Feb 21, 2023
Hi @alessiostalla,
Sorry again for the delay of my answer. As I stated in pyecore/pyecore#130 (comment) the new version should also fix this issue :). Regarding your observation with the two
forloop, as you probably undersood, indeed the secondforloop is redundant (in my opinion), I think it was here as a "fix" for a bug regarding theePackagerelation. At the endclassif.ePackage = eClassandeClass.eClassifiers.append(classif.eClass)do the same thing asePackageandeClassifiersare opposite relationship.Regarding the
EPackagename in the code (eClass) it's becauseeClassis the name of the relationship that allows you to pass from a python instance to a pyecore-world instance (from static to dynamic). The idea was to make the python module polymorphic with other pyecore objects. However, the nameeClasswas badly chozen from the beginning. I chose this one and at the end, the semantic changes regarding the receiver of the attribute. If you are on a dynamic instance,eClassis actually the metaclass of your object in the pyecore-world (as in EMF), however, if you are on a static class (a python module that is anEPackageor a python class that is anEClass), then it means "get the dynamic instance that represent this module/class". This name is badly chosen from the beginning and I still keep it for retrocompatibility issues. Perhaps in the future I'll release a new version, but that will imply some breaking changes and an obligation to use the last version of pyecoregen (that will need som patch also). The last commit I added to0.13.1introduces a new relationship between the two worlds that will replace in the future theeClassreference to pass from python-world to pyecore-world:dyn_inst. The advantage is that if you calldyn_inston a dynamic instance, it returns self. If you call it on a static element (class/module/package), it will return the dynamic instance.I didn't documented it yet as the name will perhaps change in the future.