Having country list hard coded is restrictive

[Nirys]

We're looking at adopting DayByDay for a client project, however being based in Australia we don't have an option for Australia out of the box.

Would you consider having this data (country, currency code, etc.) in tables so that it's more easily extensible? I'm totally keen to submit a PR for this if it would be a welcome feature.

[Bottelet]

@Nirys I would be open to this, but can you tell me your use-case? The reason it is on a file currently is because it's static information, and the users can't change any of the settings.

[Nirys]

@Bottelet , I guess I see a couple of things here:

• The current list is nowhere near representative of all countries in the world. Having this list be database based, makes it easier to add them over time or for new installs to add a country they need, without having to modify the core codebase.

• Country data, while changing rarely is not actually static. The names, currencies, phone codes, etc. of countries do change over time. Furthermore, people may wish to use a default set of formatting and language code that differs from what the code provides for their country. Editing core code to provide this seems short sighted.

I'm not necessarily suggesting that there's a front end to edit the countries, merely that they get moved out of an Enum into a database table. That way it's possible to add/update/remove them from migrations in a vendor module or similar. I prefer to do extensions/modifications as vendor packages so that the core code base remains in line with current published head.

[Bottelet]

@Nirys I will stick with it being in files for now, as I don't see the advantages of having it in the databases, there shouldn't be a need to add any other country than your own to the options. Thanks for the suggestion, I appreciate it.