Use a config file instead of code for enum definitino

[angaz]

Hi. I like the project. I'm wondering if you have considered or would like to have a contribution where the enum definitions are in a config file instead of in a code stub?

I think it would be quite interesting to have them defined in something similar to how go-swagger or sqlc does it.

An idea of a possible configuration file:

version: 1
enums:
  - package: animal
    target: internal/animal
    name: Animal
    type: int
    alias:
      "+": Plus
      "#": Sharp
    values:
      cat:
      dog:
      fish:
      fish++:
      fish#:
  - package: color
    target: internal/color
    name: Color
    type: int
    values:
      Black:
      White:
      Red:
      Green:
        - value: 33
          comment: Green starts with 33
      Blue:
      grey:
      yellow:
      blue-green:
      red-orange:
      yellow_green:
      red-orange-blue:
    generate:
      marshal: true
      lower: true
      pointer: true
      mustparse: true

[abice]

My first reaction is that I don't like that as an option as I have not run across a situation where I think it would be better to do it that way. The point of the project is to keep the enum definition close to the code that it is defined in, rather than having a config file to update when I need to add a value. I can simply "go to definition" of the enum, and add a value, rather than trying to find it in a giant config file.

That doesn't mean the idea won't grow on me, but it's not something I want to put effort into supporting right now without knowing a good use case.

The links you sent just point me to the base projects, which doesn't show me anything about the use case you're referring to. I'm fairly familiar with go-swagger, and I know that what they have is like a "merge" ability to override what's in code, or just use the config file outright. If there is a better use that I'm not seeing, please expand upon your idea and let me know.

Thanks for thinking of fresh ideas for the project though... I'm definitely open to new ideas, but this one seems like a lot of effort without much gain to me.

[angaz]

Ok. Sure. It was just an idea. I'm not attached to it. I didn't think about the "Go to definition" use-case, that makes a lot of sense.

The go-swagger project generates some API handlers and client libraries from OpenAPI specifications. I think this is a nice explanation: https://goswagger.io/tutorial/todo-list.html it's very nice for working with APIs between languages.

SQLC generates Go code from SQL migrations/queries. So it's not generating code from a configuration.

So maybe my two examples aren't the best.