Added predicate and predicate operations

[BiggerNoise]

• Added a type definition for a predicate which takes the item being generated and defines a TypePredicate func(item Type) bool
• Added member functions on the predicate for And, Or, and Not

I was hand rolling something like what gen makes automatically for a project I was recently working on. By treating the predicate functions as a defined type and defining the And,Or, etc. I was able to produce some very clean looking code:

        if !member.Claims.Any(YearsWindowSelector(endMonth, 1).And(acoEncounter)) {
            return *NewRuleResultClinicallyExcluded(ExNoEncounter)
        }
        if member.Claims.Any(YearsWindowSelector(endMonth, 2).And(examPerformed)) {
            return *NewRuleResultIndicated(1)
        }

Here, YearsWindowSelector() is a function that returns a predicate that filters claims by date. acoEncounter and examPerformed are predicates that are looking at the services rendered for a given claim.

The syntax for Not() is a bit clunky; unfortunately since there's no overloading, the receiver is the only way to differentiate the different predicate methods.

Logistics:

• I wrote tests for 'thing', but not 'other' (they would pretty much be the same). I can add those if you like.
• I did not make the predicate stuff optional. I will take a stab at that if you are otherwise willing to pull this in.
• Locally, I had to change gen/typewriters/genwriter/test/setup.go to reference biggernoise/gen and not clipperhouse/gen. I don't think that you will need (or want) that change if you're evaluating this P/R
• If you accept this, it would probably make sense to change the templates for the other methods so they take predicates. I did not do that with this P/R to avoid gunking it up. I would be happy to do so if you want to pull this in.

Hope that this can make it into your library.

[BiggerNoise]

I am curious if you have had a chance to consider this P/R.

[clipperhouse]

Hi Andy, I like it, though I will probably ask that it be a third-party typewriter. The upcoming version of gen (branch) will support easy drop-in.

(The gen binary is going to have fewer responsibilities over time, typewriters will do the work and will be importable.)

[BiggerNoise]

That makes a lot of sense.

Is the 3.0 branch close enough to stable that I can start that effort, or am I going to be better off waiting a bit?

[freeeve]

Hopefully it will be released in a preliminary form before July 8th. ;)

[clipperhouse]

@BiggerNoise Yep, it’s close! You can play with it now – please ask questions and give feedback. I need to know if the API is usable for typewriter makers.

A contract change I am considering is that the typewriter.TypeWriter interface would include one more method. Will give you the heads-up if so. But you should be able to work with the current bits pretty well.

@wfreeman Commitment hereby made. :)

[clipperhouse]

@BiggerNoise @wfreeman OK, v3 is merged into master. Please have at it and your feedback is more than welcome. Email, Twitter, am also on Slack lately: https://gophers.slack.com

[freeeve]

Excellent!

[BiggerNoise]

Thought I would give you a quick update, as I am just about done with the first pass (mostly cargo culted container).

First off, I think this is a really good design decision; very smart to get out of the way of the people who want to create custom typewriters.

The overall flow of code implementing a typewriter is well done, even if what you're supposed to do at each point isn't always immediately clear. I think that's more of a documentation thing. As I flesh out my typewriter, I'll try to include hints about what needs to happen at various points.

I do think that the evaluation of tags for validation and for template selection could be DRY'd up a bit. I would certainly expect that every implementation is going to look similar.

I also think that it might be useful to have standard tag names, 'all', 'skip'/'none' spring to my mind. Helper functions for the validation and template section would go a long way to helping these be consistent and address the repeated code. I'll see if I can't factor out some plausible candidates as I move away from the cargo cult.

[clipperhouse]

Thanks. Agree that we need more docs.

And if I understand correctly, you’re suggesting the typewriters should be even more prescriptive. Right now, if you implement the methods, I don’t much care what’s behind the curtain. We should basically lay it out for mainstream use cases and offer helper methods.

[BiggerNoise]

I don't think you want to close off the possibility of wild and wacky implementations. However, it does seem that you might see quite a bit of tag names corresponding 1:1 with format names.

For my purposes, I know that I would also want shortcuts to handle:

• A type asking for all of the add-ons that a particular typewriter offers
• A typewriter having a 'common' template which is included if any of the other templates are used.

Hopefully, I'll have a chance to work on this a bit tonight. I'll try and separate out that logic. when I can get things to a pushable state, I'll drop you a line. We can pick up the conversation from there.

[BiggerNoise]

OK. Have a look at https://github.com/BiggerNoise/predicate

I factored the bulk of the typewriter logic into simple_typewriter.go. Have a look when you get a chance. There's still some work left to do:

• I am not handling Imports just yet
  • I don't have the "all" tag item
  • I think the tag item to template mapping should be case insensitive
  • It needs quite a bit more testing

I'd sure love to get any feedback you guys might have before I start off on those. We can do that here or open an issue over there (and close this P/R).