Builder inheritance or generics to remove boilerplate

[ninjarobot]

There is a lot of boilerplate between builders where we have to repeatedly create things like name, add_tags, and depends_on. Could we use some inheritance or some sort of generic builder to make that consistent across builders?

[isaacabraham]

I've been thinking about this too. I've not an easy one to solve really - F# doesn't support traits or mixins. The only solutions I could come up with are :

1. Inheritance - but I would only use this for things that we know are used across all resources really. And it might get tricky in the future if we bring back Typed Resources (probably a v2 feature).
2. Go for more of a "composition" approach. The records would still have fields, and still have members, but we would add some reusable functions and / or types that would plug onto the existing records.
3. Look at a combination of extension methods and SRTPs. You can actually add keywords as extension methods, so we could add e.g. an interface e.g. ITaggable, and extension methods on them would automatically "light up" extra keywords. This is something worth further investigation...

[isaacabraham]

Using Interfaces and Extension Methods

This approach is almost like type classes and appears to "just work". I don't quite know how (!). Let's take the example of Tags.

1. Define an interface

Create an interface - lets call it ITaggable:

type ITaggable<'TConfig> =
    abstract member AddTags : state:'TConfig -> (string * string) list -> 'TConfig

2. Don't change builder record

First, keep your config type with the field on it:

type MyConfig =
    { Tags : Map<string,string>
      ....
    }

3. Remove builder methods for Tags.

Remove all the attributed methods e.g. AddTags and AddTag

4. Implement the interface on the builder

type MyBuilder() =
    interface ITaggable<MyConfig> with
        member _.AddTags state pairs =
            { state with Tags = pairs |> List.fold (fun map (key, value) -> Map.add key value map) state.Tags }

Who provides / receives "state"? Who knows. F# does it. It's magic.

5. Provide ONE OFF extension methods

These extension methods provide the keywords for tagging and delegate to the interface implementation:

[<AutoOpen>]
module Extensions =
    type ITaggable<'T> with
        [<CustomOperation "add_tags">]
        member this.Tags(state:'T, pairs) = this.AddTags state pairs
        [<CustomOperation "add_tag">]
        member this.Tag(state:'T, key, value) = this.AddTags state [ key, value ]

That's it. Now every type that implements ITaggable will magically get these keywords. We should be able to apply this to things like Dependency and Name as well (and any other "reusable" set of keywords).

I'm quite excited about this because it provides a way to abstract over a type whilst still allowing us to shape the data however we want at the builder level.

What do you think, @ninjarobot?

@cartermp Have I missed something here or have I stumbled on something that appears quite powerful here?

[isaacabraham]

There's an experimental branch which applies this technique to all depends_on builders and some of the tag ones. I think that we could possibly take this further with SRTPs but even this improves matters - what do you think?

[ninjarobot]

I agree the extension methods can simplify what is needed on a builder and don't couple builders to an inheritance hierarchy - this seems like a good approach, but we still have to implement the fields on all the config records and implement the interface on all the builders. What if we have a record for all of the common ARM Resource elements and change the config records to use that as a common attribute like Resource instead of each having Tags, Name, and Dependencies? That seems like it would open up the possibility of using SRTP for the builders since all the config records would have this same common Resource attribute. Could we then take out any methods to implement in ITaggable and use it only as a marker interface for adding the extension methods?

[isaacabraham]

I actually don't mind so much explicitly declaring those things - not all resources have dependencies or tags; some don't have locations etc. In fact the only thing we can rely upon is a name I think.

Moving to an SRTP approach could be a nicer approach - that's something that needs further exploration - we could still just check for e.g. existence of a Dependencies field which is a ResourceId Set etc. However, you'd still have to implement some interface - or we would need to change IBuilder to be IBuilder<'TConfig> or something.

The actual current implementation for each of the interfaces is a one-liner already - this is taken from WebApp but it's the same lines everywhere:

interface ITaggable<WebAppConfig> with member _.Add state tags = { state with Tags = state.Tags |> Map.merge tags }
interface IDependsOn<WebAppConfig> with member _.Add state newDeps = { state with Dependencies = state.Dependencies + newDeps }

Getting the right blend of ergonomics is difficult :-)

[isaacabraham]

I had a chat with some people that know SRTPs a lot better than me - I don't think that this will be possible because we would need to put the constraint on the generic type of the interface, which I believe is not supported in F# - you can only place SRTP-style constraints on inline functions.

I think that this strategy, which not entirely free of boilerplate, will really help - I've already applied the same technique between Functions and Web Apps to solve a long-standing gripe of mine that meant we couldn't easily share keywords across builders.