First great enums gem! Another (older) alternative enums gem

[geraldb]

Hello,

sorry if this is the wrong (communication) channel. First let me say that I love your (literal) enums gem.

Some time ago I coded-up my own little enums gem - see https://github.com/rubycocos/core/tree/master/enums.

Anyways, just trying to say hello and maybe if interested a discussion / debate or such on enums in ruby follows.

Did you look at any alternate enum gems in ruby? Might be an idea to bring all or some of the ruby enum gems coders / programmers / designers together for a "consensus" on how to promote the idea to the ruby universe at large or such or see what's different and what's the same (and getting recoded time after time after time after time).

Again sorry if this is the wrong channel. All the best. Cheers. Prost.

[joeldrapper]

Hey 👋 I hadn't seen that before. I’ll definitely check it out!

I’m totally down for working together to promote native-(ish) Ruby enums. I’m especially interested in using them in a Rails context. Did you see the rails plugin?

Do you want to grab some time in my calendar? https://savvycal.com/joeldrapper/pair

I’ve been meaning to take another look at this gem as I think there are a number of performance optimisations I should do.

You should also check out Ecase, which was designed to work with Literal Enums.

[geraldb]

Thanks for your response and moving the ticket over to the discussion forum.

I am personally not much of a user / fan of rails BUT a big user / fan of activerecord. So not sure if your plugin can get used "off-rails" with activerecord only.

Thanks for the invite. Let me first gather some more commentary to get a better understanding of your (enum) work (to not waste your time by being unprepared).

Also thanks for highlighting the ecase gem - amazing work - the idea to turn enums into abstract data types (adts) with pattern matching is great. No surprise that I tried my own litttle gem enum addon/ experiment a while ago - see https://github.com/rubycocos/core/tree/master/safedata.

PS: Anyways, to repeat the idea is bring in more rubyists to the discussion / debate on enums. I posted an invite on ruby flow.

[geraldb]

Discussion: Code (Class) Generation vs "On-The-Fly" Dynamic Method Missing "Magic"

Looking into your literal_enums machinery / code I see (or my understanding is) that you are using some kind of dynamic method missing "magic" e.g.

class << self
    def method_missing(name, *args, **kwargs, &block)
      return super unless name[0] == name[0].upcase
      new(name, *args, **kwargs, &block)
    end
# ...
end

Anyways, I opted for using "ahead-of-time" code generation, that is, a subclass of a base enum class gets auto-generated via a "macro" to avoid any method_missing "magic". method_missing "magic" is usually considered as an anti-pattern and bad practice (because of unpredictability and performance issues among other cons).

Q: Why opt for method_missing "magic"? What convenience syntax / notations does it give you that you cannot get with "classic" code generation?

[joeldrapper]

I wanted to make Enums feel like a native feature. The syntax was heavily inspired by Kotlin and I don't see method_missing as an anti-pattern for things like this. method_missing is slow, but it’s only used once on app boot. After that the enum members are constants.

If we needed to avoid method_missing magic, I’d personally prefer this definition as it communicates that we're setting a constant.

class Color < Enum
  Blue = new("#0000ff")
end

I think the examples you posted don't communicate the constants for the enum members.

[geraldb]

The syntax was heavily inspired by Kotlin

The (alternate) enums syntax (above) is heavily inspired by Ruby's Struct :-).

The (alternate) syntax posted (above) is the "shortcut" or convenience version - you can also code the enum "by hand" because there is no "magic" - it's all ruby (with no method_missing "magic") e.g.

class Enum
  def initialize( key, value )
    @key   = key
    @value = value
  end
end

class Color < Enum

  RED   = new(:red,   0)
  BLUE  = new(:blue,  1)
  GREEN = new(:green, 2)

 # ..
end

So a first difference looks like the enums gem uses key / value pairs for enums while the literal_enums gem only uses values (but no keys?) ?

[joeldrapper]

So a first difference looks like enums uses key / value pairs for enums while literal_enums only uses values (but no keys?)?

That's right, in LiteralEnums, the keys are the constant names so they don't need to be defined separately.

[geraldb]

I am always for minimalism and keeping it simple. So it looks like your gem is closer to the "module" style while the enums gems is closer to the "key / value" style with a hash (table) e.g.

enums in ruby? No library needed, just use symbols :-) or use constants. Example:

Color = [:red, :blue, :green]
Color[0]  #=> :red
Color[1]  #=> :blue

# -or-

Color = {red: 0, blue: 1, green: 2}
Color[:red]   #=> 0
Color[:blue]  #=> 1
Color.keys    #=> [:red, :blue, :green]
Color.values  #=> [0, 1, 2]

# -or-

module Color
  RED   = 0
  BLUE  = 1
  GREEN = 2
end
Color::RED       #=> 0
Color::BLUE      #=> 1
Color.constants  #=> [:RED, :BLUE, :GREEN]
# ...

Is see Color.member gets you all (enum) constants in literal_enums (and there is no Color.keys as it seems kind of redundant anyway). Now the million dollar question is - if there's anything missing or can't be done without "explicit" defined keys (not auto-derived from the constant name) [I will have to research as I have no quick answer "of-the-top-of-my-head" now].

[joeldrapper]

Now the million dollar question is - if there's anything missing or can't be done without "explicit" defined keys (not auto-derived from the constant name)

Yeah, I don’t think there is. At least there hasn’t been for my use-cases. I like Module-style enums, but I wanted some extra functionally from the enum class and members:

On the enum class, for example, I want to be able to cast a value into a member, e.g. Color.cast("ff0000") returns Color::Red. On the members, I want to be able to define methods like the toggle example here. And of course methods defined on the enum class should be available on all the members.

[geraldb]

Discussion: Q: What ruby enum gems are out there?

The line-up so far:

• literal_enums => https://github.com/joeldrapper/literal_enums
• enums => https://github.com/rubycocos/core/tree/master/enums
• ruby-enum => https://github.com/dblock/ruby-enum
• renum => https://github.com/duelinmarkers/renum
• typesafe_enum => https://github.com/dmolesUC/typesafe_enum

Any others? What's your favorite enum style / gem and why?

[joeldrapper]

I think the most popular “enum gem” is probably Rails, or more precisely, ActiveRecord. I’m not aware of any others.

[geraldb]

If I dare to disagree - the rails "enum gem" is not really an enum as it will NOT work outside of ActiveRecord (and, thus, needs / assumes a backing database) - I might be wrong and missing something on "rails enums". Anyways, thanks for all your great commentary.

PS: One way is to search rubygems for enum or enums (and check the downloads as a rough estimate on "popularity") => https://rubygems.org/search?query=enum or https://rubygems.org/search?query=enums But for sure lots of "false positives", that is, rails (activerecord) enum addons / helpers / extensions / alternatives (see above why they do not really count or help.

[joeldrapper]

I agree it's not an "enum gem". But it is probably the only implementation of enums that many Ruby developers have ever used.

[geraldb]

Yeah. Kind of a missed opportunity that the rails enum is bound to (only useable w/) the activerecord (SQL database) machinery - for sure would help adoption (of enums as "first-class citizen") if it were more "generic" and a "basic" (data) type like Hash, Array, String, etc. And as far as I can tell your enums gem plus activerecord / rails addon shows that it's possible.

Anyways, thanks for your time and commentary - I was hoping to pull in more (rubyists) to the (enum) discussion but alas it looks like that won't happen any time soon - thus, all the best and keep up the great work. Greetings from (near) Vienna, Austria.