Version: 1.2.90 (using KDE 3.2.2, compiled sources) Compiler: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) OS: Linux (i686) release 2.4.20-6 This was previously reported in bug number 65402 which is marked as fixed, but it seems to be busted again. I have a class in the global namespace that I am trying to move down into a package. Because I can't seem to do that (I'll be reporting that in another bug report) I figured I would create the same name in the sub namespace, copy things to it, then delete the original. Umbrello gives me an error message stating the names are not unique. Even though they are in two different namespaces/packages. I tried doing this via the list view. I am using CVS current as of 06/15/04
> I have a class in the global namespace [...] > I figured I would create the same name in the sub > namespace, copy things to it, then delete the original. The hitch here is the class in the global namespace. Inner classes have visibility to outer classes. If you move the class from the global namespace to a different package then things should be fine - can you verify?
Because of issues documented in bug #83448 I can't move the class in the global namespace into a sub package. However, if I create a new class of a different name in a sub-package, then attempt to create a class of the same name in a different sub-package, it works. It shouldn't matter what the package path is however. I should be able to create a class in any package that doesn't already have a class of that name. Foo::bar is not the same as ::bar or Foo::Foo2::bar
> It shouldn't matter what the package path is however. > I should be able to create a class in any package that > doesn't already have a class of that name. In principle I agree, but we have to be careful here: > Foo::bar is not the same as ::bar or Foo::Foo2::bar However, Foo::Foo2::bar has visibility of Foo::bar which in turn has visibility of (i.e. re-declares) ::bar. Now, it might be that a given programming language has a rule that says that inner declarations hide same-named outer declarations, but that behaviour is still programming language dependent.
> However, Foo::Foo2::bar has visibility of Foo::bar which > in turn has visibility of (i.e. re-declares) ::bar. > Now, it might be that a given programming language has > a rule that says that inner declarations hide same-named > outer declarations, but that behaviour is still programming > language dependent. OK, I understand that a specific language may not handle this type of declaration hiding. However, does it make more sense to put the smarts for this in the UML editor, or in the code generation? Just my $0.02, the smarts for different languages should be in the I/O for the particular language, not burried in the more generic UML editor. (Some languages don't handle enums or for that matter namespaces, but that doesn't mean we leave them out of the UML diagrams.) I think umbrello is a great tool, and getting better all the time, allowing this type of (IMHO) just another increment towards being the best.
*** Bug has been marked as fixed ***.