jessecoretta / go-schemax Goto Github PK

Research the feasibility of replacing the native schemax.Collection types with go-stackage Stack instances.

Package stackage affords all of the capabilities schemax needs, and its integration would (seemingly) reduce the mass of the code base quite a bit. Additionally, stackage is designed to work seamlessly with type-aliasing, which is absolutely what schemax should do, given the number of types needed.

Describe the bug
As stated on goreportcard.com:

The cyclomatic complexity of a function is calculated according to the following rules: 1 is the base complexity of a function +1 for each 'if', 'for', 'case', '&&' or '||' Go Report Card warns on functions with cyclomatic complexity > 15.

Link: Actual report for this package (v1.1.2)

Version

• v1.1.2 and later
• N/A

Additional context
This report is a placeholder for ongoing efforts to reduce cyclomatic complexity within the go-schemax package wherever possible.

Describe the solution you'd like
Macros support is sloppy and implemented almost as an afterthought. It should be revamped in a manner similar to the Extension redesign, which discontinued use of map[string][]string types in favor of proper collection types.

Describe alternatives you've considered
Simply not using Macros will work most of the time, however certain RFCs, such as RFC2307, do require basic Alias-To-OID resolution for certain definitions during the Marshal (parsing) process. Therefore, outright abandoning macro support is not feasible ... its here to stay.

Leaving the current solution as it is would be fine too, but a revamp certainly couldn't hurt.