Community
Participate
Working Groups
Further to Bug 344395, the direct inheritance from EClassifier by ocl.ecore's VoidType (and InvalidType, and TypeType and TemplateParameterType and AnyType) is not legal. The tuple tests revealed one problem case. Rather than patching each problem as it occurs change the inheritance to EDataType. A quick experiment with VoidType showed that it fixed the problem and introduced no failures. There are minor behind-the-scenes 'API changes' that will need comment filters to suppress.
Sounds useful. Can you turn your experiment into a patch? Do you want to get it into M7?
I just changed EClassifier to EDatatype for VoidType superclass in the Ecore and re-genmodelled, then checked that the API issues were benign and suppressed them. I suspect that one of the others, most likely AnyType, just might be a problem, but VoidTypeImpl was eseentially unchanged so may be not. Since this is 'not' an API change it would be better to get it in M7 than RC1, but I don't have time. The mature Ecore is your pigeon.
(In reply to comment #2) > I just changed EClassifier to EDatatype for VoidType superclass in the Ecore > and re-genmodelled, then checked that the API issues were benign and suppressed > them. Did you also re-generate edit/editor or only model?
(In reply to comment #3) > Did you also re-generate edit/editor or only model? No. There is no generated editor plugin. The edit plugins should be regenerated just in case. In fact we should do this anyway to check that we are aligned with the latest EMF templates.
(In reply to comment #2) 5 errors, 9 failures. We then need to adjust UMLReflectionImpl.isDataType accordingly, adding exceptions for the types that are now EDataType subtypes but are not really data types. With this fix, tests pass again. I'll now re-generate the edit plugin, hoping it doesn't mess things up too badly
Dang... re-generating the edit code produces a giant diff, obviously due to minor changes in indentation. Which code formatting settings did I need to install again for the OCL code to ensure EMF generates according to the appropriate indentation / line length rules?
(In reply to comment #6) > Dang... re-generating the edit code produces a giant diff, obviously due to > minor changes in indentation. Which code formatting settings did I need to > install again for the OCL code to ensure EMF generates according to the > appropriate indentation / line length rules? Well, now I found the OCLCodeFormatter.xml in releng, installed it, re-generated, but now the line breaks and indentation are messed up in yet another way. However, this time I propose the following: as the checked-in code formatter should be the standard for anyone joining the project, I hope that the way I now re-generated it should be what anyone gets trying to re-generate as long as the checked-in code formatter is used.
Created attachment 194456 [details] Inherit from EDataType instead of EClassifier The patch shows three things: 1) Changes are required in UMLReflectionImpl because an instanceof EDataType now includes things that were not included before 2) Old changes can be reverted with tests staying green as expected 3) edit bundle re-generation shows many formatting changes although specific OCL formatter from releng was used Particularly 1) sounds a bit dangerous to me. We should at least inform our clients that in case they relied on an instanceof EDataType check they should instead use UMLReflection.isDataType.
(In reply to comment #8) I'm a bit confused by the Eclipse warnings about unused API filters which keep appearing, disappearing and re-appearing. I thought I had it right, but after re-building some "unused" messages re-appeared. I now removed the reportedly unused filters again and re-created the patch. I hope it doesn't produce API incompatibility errors elsewhere...
Created attachment 194457 [details] Inherit from EDataType instead of EClassifier Reportedly unused API filters removed
(In reply to comment #8) > Created attachment 194456 [details] > Inherit from EDataType instead of EClassifier > > The patch shows three things: > 1) Changes are required in UMLReflectionImpl because an instanceof EDataType > now includes things that were not included before > 2) Old changes can be reverted with tests staying green as expected > 3) edit bundle re-generation shows many formatting changes although specific > OCL formatter from releng was used > > Particularly 1) sounds a bit dangerous to me. We should at least inform our > clients that in case they relied on an instanceof EDataType check they should > instead use UMLReflection.isDataType. I did a quick check of isDataType() calls; all a bit smelly. I think this is too dangerous. We have no effective means of communication with most clients other than breaking code and waiting for complaints. The inconvenience of a few random workarounds on mature code is small compared to the risks. WONTFIX. OCLCodeFormatter.xml is news to me... Oops. API errors do not regenerate on file save. You need a project clean at least to regenerate.
See Ed's last comment. Too dangerous for now to change inheritance of some central OCL *Type classes from EClassifier to EDataType without knowing if there are any clients out there checking for data types with instanceof EDataType.
