jessecoretta / go-schemax Goto Github PK

The new v2 schemax should offer official file and directory parsing capabilities. The v1 schemax only included an "example" main.go file for this scenario, leaving it to the end-user to devise a suitable solution on their own.

The directory parsing system should ignore files that do not end in ".schema", leaving readme files, diagrams and other parallel content alone.

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.

For the new v2 release of schemax, use the go-shifty package for simple bit-shifting Options type support

All of the package-level v1 directories, such as rfc4517 and others, should be moved within a newly created internal directory. They need not be renamed.

Add a README.md file for the internal directory explaining that copies of relevant RFC documents reside within, along with all definitions stored as exported go variables for top-level consumption by schemax. Users are free to browse these directories but need not interact with them directly.

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.

The new v2 schemax package should use ANTLR for all parsing capabilities, and should cite the official RFC4512 grammar file(s) for user consumption, if needed.

The new schemax should also offload the resultant ANTLR target into its own package, keeping typical ANTLR cyclomatic penalties isolated there. The resultant package should focus strictly on tokenization of definitions into easy type instances, such as map[string][]string. The new v2 schemax should read the instances returned by the new ANTLR package and incorporate them into more sophisticated (pointer) types, similar to v1 schemax.

The new v2 schemax package should leverage text/template for stringer output. A call to a given type instance String method should NOT call text/template, as stringer output should be preserved until otherwise indicate by the user (e.g.: update stringer following significant changes to an instance).

Allow user submission of func() string closures to gain complete control over definition presentation. Default to package-provided closure in the absence of a user-authored instance.

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.

Replace the simplistic isNumericOID syntax-checking function with calls to go-objectid's NewDotNotation function. Return-shadow all variables except the error instance which, if nil, indicates a successful parse.