Wrong code generated for enums
Opened this issue · 1 comments
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,
eClassifiers
is empty. Then, first, enums are added toeClassifiers
, and then theeClass
of each object ineClassifiers
is added to theEPackage
(that for some reason is calledeClass
). So we have theEEnum
class added to the package we're defining! And, of course, it gets removed from the Ecore package, becauseeClassifiers
is a containment relationship. I don't know the purpose of the secondfor
loop, 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.
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 for
loop, as you probably undersood, indeed the second for
loop is redundant (in my opinion), I think it was here as a "fix" for a bug regarding the ePackage
relation. At the end classif.ePackage = eClass
and eClass.eClassifiers.append(classif.eClass)
do the same thing as ePackage
and eClassifiers
are opposite relationship.
Regarding the EPackage
name in the code (eClass
) it's because eClass
is 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 name eClass
was 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, eClass
is 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 an EPackage
or a python class that is an EClass
), 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 to 0.13.1
introduces a new relationship between the two worlds that will replace in the future the eClass
reference to pass from python-world to pyecore-world: dyn_inst
. The advantage is that if you call dyn_inst
on 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.