I’ve noticed that 2019.2 with the new Roslyn backend started including the document name in namespaces.
Eg. in 2019.1 you’d get Category.Class whereas in 2019.2 you’re getting Document.Category.Class_C
Or an actual example VVVV_Schema_Core.VVVV.Schema.IBee_I instead of VVV.Schema.IBee
This is reflected when reading out type names using .NET built in functions, in the generated exported source code and in serialized type descriptions - making them both longer than seems necessary and incompatible with previous versions. Although there’s also the _I. _P and _C suffixes that are enough to make stuff incompatible.
So if I understand correctly it’s now not possible to define classes and operations in one namespace from separate documents? Meaning separating an application properly into multiple documents will result in a mess of top level namespaces?
I’m interested what was the motivation and if it’s here to stay.
It might work well enough when staying inside of VL but interacting with code generated in such non natural fashion from other .NET environments might be quite a bit of pain.
We’re at the beginning of that road regarding export of executables and dlls. For now we focused on making it work. Later on we might look into making the generated code beautiful.
The motivation of all the ugly suffixes is to not run into ambiguities. e.g. VL allows operations to be defined in any category; C# only allows static methods to be defined in static classes, not in namespaces.
This means we need to compile operations in categories to static classes. But we don’t really want to turn every category into a static class, since a category is conceptually more like a namespace. So there are some issues that need to be worked on long-term (when we want to sell stable dll export), but for now we can just export to namespace and static class, suffixes currently helping us to not run into ambiguities.
IMO it might make sense to consider bringing VL closer to C# in that sense then, operations would have to be wrapped in some explicit object that would become the static class. Be it a region or a category like folder or both. Maybe the region could get some implicit standard name if not defined otherwise (eg. Utilities, Operations).
This would of course be a massive breaking change for patches, unless it is also done implicitly automatically, which would still keep some of the ambiguity though.
Upside of this would be that the outputted C# would be closer to the original VL patch and there would be less ambiguity and confusion and it would be easier to predict what kind of C# code you’ll get in the end.
And if such a change is to happen (for you to get cleaner exports, unless you have better solutions), then it should happen rather sooner than later when VL become much bigger.
This is what I found from my internal TODOs on this topic:
Get rid of document namespace prefix - this is much harder than I thought because any category of the same name as an imported type causes a conflict. Example System.TimeSpan , this is a class but also a category inside VL. The global alias won’t help, would need to set alias for all assemblies, currently only done for those not in the GAC.
