SimpleEnum - Use Enumerations in Elixir

Your Libraries & OS Mentoring Libraries
,
1

Hi everyone,

I have just published the first version of a library that I have been using in my projects for over a year now: SimpleEnum - a simple library that implements Enumerations in Elixir.

SimpleEnum was designed to be :

  • fast: being based on a macro system, access to the Enum will be resolved at compile time when it is possible
  • simple: the use of the library has been designed to be as simple as possible for a developer to use. In addition to providing Enums, it automatically defines their types and provides an introspection system.

Examples of uses can be found in the documentation : SimpleEnum — simple_enum v0.1.0

Proposals :

To improve SimpleEnum, I had several ideas like

  • Add the defenump function in order to create private Enums: currently, all Enums are public
  • Add an EnumValueError exception for developers who need rescue. Currently, ArgumentError is used
  • Add a decorator @allow_duplicate_values true or @unique false to allow duplicates values in Enum
  • Add macros is_enum/1, is_enum_key/1 and is_enum_value/1 (eg. is_color(:red), is_color_key(:red) and is_color_value(:red)) for each Enum. An example of implementation can be found here.

What do you think? Would you need a feature in the list or another one?

Any issues, suggestions or contributions are welcome.
Cheers

Links:

4 Likes
2

Hi @ImNotAVirus! Cool project… Could you elaborate on how is simple_enum different from existing packages like ecto_enum and the native Ecto.Enum module? I’ve been using ecto_enum for some time now and have been meaning to migrate to the new native Ecto.Enum. I think a comparison would be great to understand the value proposition of your package. Cheers!

1 Like
3

Thanks for your interest!

Short answer:
The two main differences are that SimpleEnum does not depend on Ecto (it has no dependencies) and it adds Enums at compile time, not just at run time.

Long answer:
As mentioned in its documentation on reflection, Ecto.Enum's introspection is only at runtime.

I originally wrote SimpleEnum because I needed to be able to work with Enumeration at compile time (in guards for example).

For example, let’s say I have a file that looks like this:

# <access_type> <value>
1 value1
2 value2
1 value3
....

Now, let’s imagine that I only want to display values with access_type 1 (because they are users data). I can do something like that:

def print_value(1, value), do: IO.inspect(value)
def print_value(2, value), do: :ignore

But here, why are we only printing value with type 1 ? The code is not really explicit.
A better solution could be:

@user_type 1
@admin_type 2
def print_value(type, value) when type == @user_type, do: IO.inspect(value)
def print_value(type, value) when type == @admin_type, do: :ignore

Now the code is much more explicit. It is easy to understand that we do not want to display data belonging to an administrator.

But what if several modules need to define these access types. The best would be to define a module that exports these constants.
This is what SimpleEnum does:

defmodule MyEnums do
    import SimpleEnum, only: [defenum: 2]
    defenum :access_type, [user: 1, admin: 2]
end

def print_value(type, value) when type == access_type(:user), do: IO.inspect(value)
def print_value(type, value) when type == access_type(:admin), do: :ignore

Here, my example is probably not the best, because you can easily rewrite it without guard (with a case for example) but sometimes it is not possible.

Conclusion:
I think SimpleEnum is not intended to replace ecto_enum or the native Ecto.Enum module but rather to add compile time functionality to them.
In the documentation, there is an example where you can see SimpleEnum and the native Ecto.Enum working together.

4 Likes
4

Compile-time checking! Love it.

Thanks for sharing.

1 Like
5

How does simple_enum compare to ex_const?

6

Thanks for the question.

I’ve never used ex_const so my answer probably won’t be complete but here are the main differences I noticed.

First of all, you must know that when writing SimpleEnum, I got a lot of inspiration from how Enumerations work in C++. This explains some of my design choices like the fact that it is impossible to have 2 times the same key in an Enum.

Difference 1: with ex_const, an Enum can have duplicates keys and values.
This is a valid code :

enum type do
    key1 	0
    key1	1
    key1	1
end

iex> Enums.type(:key1)
0

Here SimpleEnum will raise an exception at compile time:

defenum :type, [key1: 0, key1: 1, key1: 1]
# ** (CompileError) tests.exs:13: duplicate key :key1 found in enum Enums.type

Difference 2: ex_const does not support lists of keywords for creating Enums
With SimpleEnum, you can do

defenum :type, [:key1, :key2, :key3]

iex> type(:__enumerators__)
[key1: 0, key2: 1, key3: 2]

Difference 3: ex_const can be used at compile time to get a value from a key but not the opposite.

enum type do
    key1 	0
end

# Valid: when x == 0
def test(x) when x == Enums.type(:key1), do: x
# Raise
def test(x) when x == Enums.type(0), do: x
# Raise
def test(x) when x == Enums.from_type(0), do: x

With SimpleEnum you can do

defenum :type, [:key1]

# Valid: when x == 0
def test(x) when x == Enums.type(:key1), do: x
# Also valid: when x == :key1
def test(x) when x == Enums.type(0), do: x

Difference 4: ex_const does not seem to have any introspection helper.

5 Likes