Change 'methods' in definitions to be more generic

[ppeble]

This one is gonna be tough. In order to complete the transition to completely generic YAML in our definitions (thereby allowing the definitions to be used in other languages) we will need to come up with a DSL for removing the current ruby code that makes up the definitions. I don't have solid ideas yet for what we will do but I will use this issue as a way to propose ideas going forward.

Example:

afl_grand_final:
    arguments: year
    source: |
      case year
      when 2015
        Date.civil(2015, 10, 2)
      when 2016
        Date.civil(2016, 9, 30)
      when 2017
        Date.civil(2017, 9, 29)
      end

This could be done as follows:

afl_grand_final:
    arguments: year
    logic:
      if:
        argument: year
        value: 2015
        then: 2015-10-2
      if:
        argument: year
        value: 2016
        then: 2016-9-30
      if:
        argument: year
        value: 2017
        then: 2017-9-29

There are a few immediate concerns:

1. There is some relatively complex logic in some of the methods. It might be difficult to make a DSL that isn't just...ruby-like. I'm not sure how to approach this.
2. There are a few cases where a method will call one of our 'common' methods. For example, 'easter' is a 'common' method that anyone can call but are considered 'private' inside of the ruby holidays code. I think we would need to define these 'common' methods in these definitions and then make them callable somehow. This could be very difficult.

[ttwo32]

This is a very difficult.
I don,t have a solid idea too, but it,s very interesting.

[ppeble]

I was stressing a bit about this last night but then I reminded myself of something: we are already doing code generation based off of a DSL. That's exactly what our generated ruby definitions are today! This is just making it repeatable instead of allowing for raw ruby.

If you think about it that way it is a little less intimidating (for myself, at least). 😄

[ppeble]

Okay, I think I have officially given up. I banged my head against this for a few days and I just...can't figure out a way to come up with a simple DSL that covers the existing custom methods we have. Things just got ridiculously complicated when I started trying. I was basically coming up with some kind of source parser/tokenizer. I kept feeling like I was missing something obvious (I still do) but...I just can't see the simple solution. I kept thinking "This is crazy complex, what am I doing".

So the solution I came up with is specifying "ruby" source in the definitions. This means that when I start adding a golang client I will need to add custom go code for each existing method. It also means that new custom methods will require someone to write custom code for each custom method for each language we eventually have. That sucks. I recognize this. But it's a problem for the future. I think I'm effectively punting and hoping that someone way smarter than me comes along to solve my problem before I need to worry about it. 😬

The solution I have will let me make minimal changes to the ruby project AND start writing the golang project I've been dreaming about for a while now. It also frees me up to figure out a way for people to test their definition changes against downstream repos (i.e. ruby) before submitting a PR, which I feel is a bigger problem now.

[ppeble]

Addressed by #79! Closing this issue.