Yes but the macros should be in ecto or absinthe. I was thinking of something simpler that ecto and absinthe can parse, not a universal data structure that will satisfy both cases. Now when you add a new value in ecto then absinthe will fail at runtime when receiving it. It should be catched when both share the same enum values.
śr., 18 gru 2024, 15:32 użytkownik Austin Ziegler <halosta...@gmail.com> napisał: > On Wed, Dec 18, 2024 at 12:35 AM Daniel Kukula <daniel.k...@gmail.com> > wrote: > >> I would like to start a discussion about adding a new enum data structure >> to the language. >> >> From the Rust documentation: enums provide a way to express that a value >> is one of a possible set of predefined values. >> >> I understand that the type system can solve some problems related to >> this, but I believe a dedicated data structure would be highly useful. >> >> For example, I am working on a project that uses Ecto, Absinthe, and >> Protobuf. Each of these libraries defines its own enum type, which is >> incompatible with the others. While the Enum namespace is already taken, >> we could use alternatives like Variant, Choice, or Tag. >> >> Having such a data structure defined at the language level would greatly >> simplify the process of sharing and translating enums across different >> libraries. This way, all libraries could rely on the same structure. For >> Ecto, if we wanted to store enums as integers, we could enforce a mapping >> that raises an error when not all possible values are covered. >> >> Examples from other languages include enums in Python >> <https://docs.python.org/3/library/enum.html> and Rust >> <https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html>. In many >> other languages, module-level constants are often used for this purpose. >> >> I’d love to hear your thoughts on this! >> > > Macros or code generation are really going to be the way that this needs > to be handled, because what Ecto needs with enums is very different from > what Absinthe needs from enums (and the Ecto version differs *internally* > across adapters, because the underlying database implementation of an enum > type changes) and itself is likely different than what Protobuf needs > (which probably mostly stores enum values as integers). I agree with the > desire to have a common interface, as I spent months over the last several > years trying to come up with ways to resolve our PostgreSQL enum types > (implemented well before Ecto.Enum) with our GraphQL enum types > (implemented in Absinthe). > > The best that I found I couldn't use because it doesn't have a licence > attached and predates the introduction of Ecto.Enum: > https://gitlab.com/ex-open-source/enumex > > I really don't think that this can be solved at the language level > > -a > -- > Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca > http://www.halostatue.ca/ • http://twitter.com/halostatue > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/1JZytnG6xDw/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQtyrzX4TMOX8MDTm4ATv0E0CaKGpKXwPsdsOqCqXr%2Bx%2BQ%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQtyrzX4TMOX8MDTm4ATv0E0CaKGpKXwPsdsOqCqXr%2Bx%2BQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/CAMvQ6WODpY48kuzQd_rhMeFh5K40yfFy_cd4450E-ce4R1YBsg%40mail.gmail.com.
