Community
Participate
Working Groups
Lots of the Sirius diagram's runtime code was originaly (a long, long time ago) generated using GMF Tooling. This was just for initialization purpose and we've abandonned the idea of ever regenerating it, but the resuling code structure is full of artificial complexity which do not make sense in our case. Lots of simplifications are possible that would make our diagram's runtime smaller, less complex to understand and maintain, and even maybe more efficient (the current codebase is so complex to understand in places that I'm pretty sure we do a lot of redundant work because it's not always obvious that the work will already be done by some other listener registered dynamically somewhere else; see bug #443518 for the kind of symptoms this can cause). I'm not putting this ticket in a particular version because by definition the work is very open ended and more a medium/long-term improvement theme than a task with an obious "done" criteria. At some point in the future, if/when the general shape of the code has improved enough, we'll close this one and open more specific tickets for more focused improvements. Note that the GMF runtime we heavily depend on can be considered on "life support". Historically it was useful to depend on it so that any bugfix or improvement there would benefit us, but in the current situation I don't see this happening. This means its OK to "inline" in Sirius code from GMF that we currently reference if that can enable further simplification in our code base. An example of what I mean: if we have in Sirius a class A which extends some intermediate class B from GMF just to reuse some code, but nobody cares that "new A() instanceof B", it's OK to incorporate B's code directly in A if the result is simpler (one less level in the inheritance hierarchy).
