You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as I already mentioned in #119 I switched from static generated code to dynamic loaded. For some export function I have a lookup dictionary where I use 'EInt, EFloat, ...' (classes not strings) as key and set a converter function as value.
If a load the model dynamical the pyEcore classes (EInt, EFloat) will be referenced via a EProxy. Because the EProxy has its own hash, the pyEcore classes which are imported are different. The EProxy has an __eq__ which references to the real class but in this case the hashes are used.
Maybe it was not the best idea to use the class as key, but I want to share this experience with you.
Best regards,
Andreas
The text was updated successfully, but these errors were encountered:
Indeed, the hash thing for proxies is tricky. The same problem occurs in EMF with unresolved resources, but in your case, it would be better to avoid the proxy as Ecore is always known. I'll see if I can deal with a less lazy way of deserializing xmi, avoiding this for EMF/Ecore basic types.
Hey @aranega
as I already mentioned in #119 I switched from static generated code to dynamic loaded. For some export function I have a lookup dictionary where I use 'EInt, EFloat, ...' (classes not strings) as key and set a converter function as value.
If a load the model dynamical the pyEcore classes (EInt, EFloat) will be referenced via a EProxy. Because the EProxy has its own hash, the pyEcore classes which are imported are different. The EProxy has an
__eq__
which references to the real class but in this case the hashes are used.Maybe it was not the best idea to use the class as key, but I want to share this experience with you.
Best regards,
Andreas
The text was updated successfully, but these errors were encountered: