[udm-dev] udm_ns release

[Zsolt Kalmar]

Endre,

> I'm still seeking for a solution, either with "typedef", or with
"using
> namespace" directives which does not imply to change the whole
generator,

We tried a few tricks and they did not work because all the heritage
source codes mix fully qualified names and "using namespace" directives
and it causes ambiguity :
namespace A
{
  namespace A
  {
    class C {};
  }

  typedef EndreFeleExtra::C C;
}

void main()
{
  using namespace A;
  C c;
  A::C c1;
}

However, if the extra namespace name differs from the package name like
this:

namespace A
{
  namespace EndreRagaszkodikHozza
  {
    class C {};
  }

  typedef EndreRagaszkodikHozza::C C;
}

void main()
{
  using namespace A;
  C c;
  A::C c1;
}

It seems working on this toy sample.
But, I think that this type of solution makes the generated c++ API much
messier, it's already hard to explain an udm genereated c++ API usage to
an entry level c++ programmer.

> but solves the issue of backward compatibility.
> (pratically,  we would have two generators, one when there is only one
> namespace in the diagram and an other when there are more)

Don't you think it could be solved by rethinking udm at certain points
and doing some code factoring?

What are problems? Let me try to collect them:

1. Uml2Xml 
It generates an extra namespce into the xml representation . Why ?

2. C++ code generation
At first glance it seems that source generation code everywhere assumes
the diagram has namespaces and starts the code generation by iterating
on them. Yes, it could introduce a lot change and conditional in the
source code, but it is still doable.

3. Dom backend, xsd
Probably it is the hardest part because the xsd looks different if it
has a namespace. Some namespace treating functions need to be rewritten
in UdmDom, too.

3. Uml c++ API usage
Uml meta model is in "UML" namespace. Earlier it was not, so it should
be remain as it was. I know that all udm source codes have been heavily
modified in order to use "uml::uml::", but it should not be a reason for
not doing the changes. Anyways, probably it is less effort than
adjusting all the dependent applications like Great.

4. OCL?
What else?

Thanks,
zsolt