Severe Rename Bug

[Barry_Pearce]

Be extremely careful naming/renaming classes!

We develop with C++ and most classes have a #include of <string> in the CG options  - we consider string to pretty much be a fundamental type and do not require developers to draw relationships to it.

Unfortunately we created another class in the model which was initially called string - and then I asked for it to be renamed to EnhancedString - namespaces or otherwise the confusion would be too great...

So the chaps renamed it. Unfortunately EA now progressed through the entire model changing every instance of the type string to EnhancedString. argh.

Be warned - EA has an issue in that return types, and operation parameters etc are not qualified by their namespace, indeed doing so means EA no longer recognises the relationship with the original class (2 faults we have already logged).  This new fault compounds the lack of scoping and will make changes across your model that you do not want..

So the bottom line is - be VERY VERY careful if you have two classes with the same name in separate packages - EA will not properly distinguish between them. And be especially careful not to create classes for types such as int, float, double etc and then rename them to something sensible......

This fault will be raised by the end of today in our latest bug reports to Sparx.

[benc]

Hi Barry,

Thanks for the note. We've made an update for 732 that should prevent this side effect.

Note: if you select a type from the drop list or use elipses button to choose types, EA does actually maintain an internal reference to the underlying classifier. So changes to other classifiers with the same name will not change the type.

Here's a simple workaround to get your data types back:
- Rename EnhancedString back to "string" (you get your original string types back)
- Copy the "string" class as new (ctrl+C, ctrl+shift+V) and name it EnhancedString
- Delete the original string class (now your left with EnhancedString- the copy- and your original attribute types)

I hope this helps. You feedback so far has been most helpful and is appreciated.

Regards,
Ben

[Barry_Pearce]

Cheers,

Good news it keeps the internal refs - so its not quite so severe....

Got another doc on the way to you + python support tonight

[Barry_Pearce]

Just a quick comment about the internal refs - I think we have already raised it - if not its in the new document coming today - due to code generation issues (i.e. the assumption that you import every namespace - which is more unusal in C++ - whereas this is standard in Java) we have had to add scope to paramters which means they are de-coupled from the class they relate to - this means name changes are not propagated....and this is similarly true of & and * - they too break the link to the class AFAIK...