iso8583
iso8583 copied to clipboard
Exporting CreateFromJsonFile Method
I need -as an user of the library-, to generate the message specification from a Json file.
Thus, moving a little bit the code it could be possible with just importing the specs
package, so that I would call:
specs.CreateFromJsonFile(...)
Which sintactically makes sense, since the specification is created from the json file.
This method was used (and only) by the /cmd/iso8583 folder, but since this one is calling the specs
package I decided that the best was to move into this last one to avoid a cyclic dependency.
Hopefully makes sense
@adamdecaf
resolve #183
@miguelalcantar, I want to thank you for your contribution! You improve the package by providing feedback and giving time to submit the issue and change the code. It's priceless!
Let me share my feedback on the PR.
Using specs.Builder.ImportJSON(raw)
directly allows anyone to load that JSON from file, bucket, or any other source. So, I would keep a generic method in the core to allow engineers to use it in different contexts. CLI, which loads JSON from a file, is a good example of such context.
If I look at two versions:
spec, err := specs.CreateFromJsonFile(path)
if err != nil {
return nil, fmt.Errorf("creating spec from file %s: %w", path, err)
}
raw, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("reading file %s: %w", path, err)
}
spec, err := specs.Builder.ImportJSON(raw)
if err != nil {
return nil, fmt.Errorf("importing JSON: %w", err)
}
I see that we win only four lines of code. But, it will also introduce a place where we may want to add more such functions in the future :) So, I think it's better no keep it as is.
I'm open to hearing your thoughts.
@alovak so what you men is that is better to keep just a generic method instead of specific ones?
Right.
Can we get this merged @alovak
@wadearnold we will keep a generic approach here to allow using the Reader
interface instead of adding CreateFromJsonFile(path)
.