Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Issue-43: When --format is specified with the log method, return everyth... #57
This commit addresses Issue 43, which identifies the limitation in G::W that
The solution is to provide a G::W::Log::Custom wrapper that returns all of
If the caller of the log method specifies the format, then they are responsible
There is the temptation here to all a parse subroutine reference to be passed,
It was the cleanest solution I could think of. The alternative is to provide a way for individuals to supply their own "parse" function that that is consistent with whatever arbitrary format they provide for the output.
The ::Custom class allows them to just grab all of the output, then do something with it externally, which I think is the right call. This doesn't have to be a new class, but it should be possible to say "don't parse the output, just give it to me for post process".
Here is what I think I'm going to do: if args includes a 'format', the return will just be the raw unparsed
@estrabd Does that seem okay?
It's up to you. I would rather it throw an exception and die, pointing me to the documentation for RUN; maybe add a special section in the docs talking about "parsing custom log formats". I'd be happy to update the docs for that.
My reason for preferring a die on "format" is that without format, you're able to iterate over the parsed results. With format you're given a blob of unparsed text - it's then up to the caller to parse that blob into individual records if they wish. I'd rather get the same iterator every time I called log, and if I tried to get fancy with a format then a simple slap on the hand would set me right.
I do think that at the end of the day, your approach accomplishes what what I had done, only more directly.
Hope that helps.
I was thinking about the exception throwing route too. Now that I've reviewed the whole entire saga across the original tickets, and I see that this has never worked properly, I'm okay with the exception being thrown instead of the warning. (I was worried I might be breaking working code; that seems unlikely based on the original ticket.)
I'll work on revising the PR, or if you wanted to do that, that would be great. 8^)