Author Topic: Same name classes ignorance...  (Read 980 times)

Resistance

  • EA Novice
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Same name classes ignorance...
« on: November 20, 2018, 11:06:26 pm »
Hi.
I have been importing my C++ source directory to Sparx but unfortunately there is one important problem.
the source code contains some pairs of classes that have same name and different functionality but each of them is in separate directory and one of them is in specific namespace.
for instance my first class A is in directory1 (without namespace) and my second class A is in directory2 and it's special namespace, but surprisingly Sparx ignore one of them in import procedure and generate only one element for class A which is located in namespace.
How I can configure Sparx to generate separated element for both classes?


qwerty

  • EA Guru
  • *****
  • Posts: 10205
  • Karma: +216/-177
  • I'm no guru at all
    • View Profile
Re: Same name classes ignorance...
« Reply #1 on: November 21, 2018, 06:02:02 am »
Try Create Package per Namespace in the import options. (Honestly not using that often, so just try it.)

q.

sfrancois

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Same name classes ignorance...
« Reply #2 on: January 10, 2019, 08:47:41 am »
I have a similar issue with the import with C++ language.
I have internal classes which have the same name, for example classA::classN and classB::classN
Problem is that parsing the files EA has only one classN and linked it to classA and classB !
Would be good to have the class name automatically having scope included, so the classN becomes classA::classN in EA.

classA and classB are in the same namespace so it is not possible to have classN separated.
classA and classB could be in the same file (to reduce the number of files as we are handling hundreds of classes...) for a separation per module.

two options:
1/ EA handles correctly the class context
2/ class names needs to be unique

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6565
  • Karma: +132/-97
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Same name classes ignorance...
« Reply #3 on: January 10, 2019, 05:05:38 pm »
I have a similar issue with the import with C++ language.
I have internal classes which have the same name, for example classA::classN and classB::classN
Problem is that parsing the files EA has only one classN and linked it to classA and classB !
Would be good to have the class name automatically having scope included, so the classN becomes classA::classN in EA.

classA and classB are in the same namespace so it is not possible to have classN separated.
classA and classB could be in the same file (to reduce the number of files as we are handling hundreds of classes...) for a separation per module.

two options:
1/ EA handles correctly the class context
2/ class names needs to be unique
Sound like it's an "it's your foot issue".(1)

The name of the class is the name of the class classN.  It's not classA::classN.  The latter is the access mechanism to get at (access) classN.
The all the classes are in the same namespace, the name classN has to refer to a unique item in that namespace.
Assuming classN is marked as private (since it's internal to the other classes), that doesn't change the namespace uniqueness requirement.

(1) Just because you CAN do something, doesn't mean you should.  It is NOT a good idea to have two implementations of the same named class in the same namespace.

My AU$0.05.

Paolo

PS: That having been said, EA provides only limited support for namespace functionality (in general) over items in the browser.  But in this case, I believe EA is doing the right thing.
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6655
  • Karma: +62/-6
    • View Profile
Re: Same name classes ignorance...
« Reply #4 on: January 11, 2019, 09:26:07 am »
I believe it is a limitation in EA's reverse engineering that classes are uniquely identified by their name and file path.

Usually this results in the advice that if the file path is altered you need to update that path in the model explicitly. But it's also true that in the situation where the same name exists in two different namespaces (including parent classes) within the same file EA can't distinguish them.
Eve

support@sparxsystems.com