Wrapped utility functions in namespaces

[spoenemann]

This is a proposal following up on #1260.

• Wrapped utility functions from ast-util in namespace AstUtils
• Wrapped utility function from cst-util in namespace CstUtils
• Wrapped utility functions from grammar-util in namespace GrammarUtils
• Wrapped utility functions from regexp-util in namespace RegExpUtils
• Wrapped default value converter functions in namespace ValueConverter
• Renamed utils files with the suffix utils to be consistent (we already exported UriUtils, so we should follow that)

Using the method described in #1260, this change reduces the number of top-level exported functions from the main export of langium by 67! That number will be further reduced once #1258 is merged.

[spoenemann]

If this is accepted, I can create a public Gist listing all functions contained in each namespace. Then we can attach that to our CHANGELOG to ease the migration to v3.0.0 (we should do the same with the new package exports).

[sailingKieler]

Please also rename the tests in test/utils corresponding to the renamed files in src/utils.

[Lotes]

I saw a difference in using the namespaces. On one side you are prefixing all olds methods with „XXXUtils.abc“ and one the other side you are deconstructing the namespace with „const { abc } = XXXUtils“. Minor thing, but why is this like that? Having the deconstructor has the advantage that all changes concentrate in the header of each file.

[spoenemann]

I saw a difference in using the namespaces. On one side you are prefixing all olds methods with „XXXUtils.abc“ and one the other side you are deconstructing the namespace with „const { abc } = XXXUtils“. Minor thing, but why is this like that? Having the deconstructor has the advantage that all changes concentrate in the header of each file.

These are two options that you can use as a consumer of the library. Both are ok – it depends on how often you use the functions and whether you want to make it explicit where they come from at the usage site.

[Lotes]

These two lines are an inconsistent renaming, I think. In C# we call regular expressions "Regex". In JS we call them "RegExp", but not mix that with C# to "Regexp". See the class name.

[spoenemann]

Yes, that's why I propose to rename all instances to "RegExp" to be in line with the JavaScript RegExp object.

However, the TerminalRegExpVisitor class is not exported, but is private to the regexp-utils module, so those changes are not relevant for the API.

[Lotes]

Yes, it is private. But I would not argument like that 'because it is private, we do not have to be consistent (it even does not contribute to the API)'. You would also not start to use identifiers like i, j, k for for-loops, just because the code is not so public, like other code.

But I also see that it is just a very minor thing. I can live with this, but my consistency alert is then popping up when I see this again ^^*.

[Lotes]

Apart from the REGEX(P) renaming, everything else looks good to me.

[msujew]

Looks good! I was always a bit unhappy about the distinction of CST and AST related functions that were exported from langium directly. I think this change clears things up nicely and aligns everything with the existing UriUtils.