Preserve array square bracket pairs when parsing type names

[willibrandon]

Fixes #11

Proposed changes

• Fix the type name parser tokenize pattern to also match on left and right square brackets so that array square bracket pairs may be preserved during conversion.

Customer Impact

• Array square bracket pairs will now be preserved during conversion.

Regression?

• No

Risk

• Could break people who expect the array square brackets to get dropped but this is unlikely and not something that should be considered breaking.

Test Methodology

• Ran unit tests and the previously failing test ConvertType_IntArray_BracketsAfterType() is now passing.

[willibrandon]

I also investigated using embedded resources in xUnit tests and have that working locally now. It will be a good way to test.

[paulirwin]

@willibrandon Awesome, feel free to submit a new PR for that. Merged this one. Also I noticed that the unit test checks to see if string is translated as string, but string is not a valid type keyword in Java. String will be translated as String, likewise for Object, although I'd like a config option to support translating to the type keywords instead. I'll create another issue for that.

[paulirwin]

I was misremembering, we already do that for String, just not Object. Working on that now.

[OJacot-Descombes]

A common convention for type names is to use the C# alias in declarations and the .NET type name when accessing static members.

int i = Int32.MaxValue;

See also: C# Coding Standards and Naming Conventions

[paulirwin]

@OJacot-Descombes Currently we do not translate the right-hand side of that statement at all, as we can't syntactically tell the difference between member/property access and static access on a type without symbol resolution. (It's a lot easier for field/parameter/etc types.) For example:

class Foo {
    void bar() {
        int i = Integer.MAX_VALUE;
    }
}

gets translated almost as-is to:

class Foo
{
    virtual void Bar()
    {
        int i = Integer.MAX_VALUE;
    }
}

While we could look into this for some common static methods/properties (i.e. I'd like to see this for #22), we'd need full symbol resolution to cover every case. However, if we wanted to do a "best-guess" translation, Java does make this easier in some regards with their naming conventions, since types would be the only ones with upper-case names for code that follows the convention. I'd be happy to accept a PR for this if you're interested.