myitcv / x

Mono-repo for all myitcv.io/... Go code
MIT License
104 stars 20 forks source link

cmd/gg: revisit fixed-point approach #155

Open myitcv opened 5 years ago

myitcv commented 5 years ago

The current fixed-point logic in cmd/gg is based on the following original "requirement": that the outputs of one generator can act as inputs to another generator in the same package. It does come at a cost, however:

  1. each directive in a given package is run at least twice
  2. gg has a more complex implementation

The first cost is almost complete mitigated by the gg cache (except where you are making changes the development cycle can be slowed in some situations). The second cost remains.

Firstly, it's worth considering whether this is even a valid "requirement". The problem can, to a certain extent, be side-stepped by adapting one of the mutually dependent generators to know about the other, in effect reducing two directives (n in the general case) down to one. This would in effect leave you in a situation where for a given package, no two directives are mutually dependent.

However this doesn't guarantee that you will never encounter a situation of mutual dependence. The fixed-point logic acts as a good back stop in this respect.

As @rogpeppe observed, an argument against this (overly-)defensive approach is that some generators may be non-deterministic (unintentionally of course). This point is largely mitigated by having a CI run:

If the fixed-point logic were removed, you could still end up with zero git diff. But this would offer no guarantee you wouldn't generate a diff the second time around, i.e. by re-running gg.

Plenty of food for thought.