Support enums

[davidcelis]

It would be great if low_type could support enumerated types so we can define arguments or variables that are not only a specific type like String, but a predefined set of strings or values. I'm not really sure what the syntax for this should look like, but just to throw something out there and start the conversation, maybe it could work by providing a type expression to a new enum method that treats default_value as "acceptable values"?

Color = enum String | ["red", "orange", "yellow", "green", "blue", "purple"]

[maedi]

Interesting... I'm open to this if we can find the right syntax. LowType currently supports a "typed enum" if you will; type [String | Integer | Hash] which will allow the array to contain one or more of these types. Not exactly the same thing, you need one of a particular value. I think it comes down to syntax... if | means "or" then what means "one of"? And how do you use values for type checking in an intuitive way? How does Ruby pattern matching do this?

[caifara]

First of all: what an interesting gem!

I feel it may be the default value syntax that makes this difficult, otherwise, it could be imagined as something like:

Color = type "red" | "orange" | "yellow"

But of course, that would not be doing assignment.

Should it exist, it could allow allow for literal string values elsewhere like:

def method(var = type Integer | "cat")

Where "cat" would be like the allowed string value, without it being the default value.

I guess this is not where you want to go with this @maedi?

[maedi]

What about:

# Define:
def method(var: enum "red" | "orange" | "yellow")
# Call:
method(var: “yellow”) # No error

[maedi]

If you want enum "red" | "orange" | "yellow" anywhere in code then you could do:

my_enum = enum "red" | "orange" | "yellow"
my_var = my_enum.validate("blue") # => returns nil if invalid, "blue" if valid
my_var = my_enum.validate!("blue") # => raises error if invalid, "blue" if valid
my_var = my_enum.valid?("blue") # => returns true/false if valid/invalid

Does that make sense and seem simple enough? Or just keep it contained to method and return type definitions, and automatically validate them behind the scenes to keep it simple?

[maedi]

Or one line it:

my_enum = enum "red" | "orange" | "yellow", validate: "blue" # => Does this feel right?

Or lambda it:

my_enum = -> (value) { enum "red" | "orange" | "yellow", validate: value } # validate could be abstracted away
my_enum.call("blue")

RE:

maybe it could work by providing a type expression to a new enum method that treats default_value as "acceptable values"?

How would it look when it accepts a value for the enum as well? (the validate: above or | in my comment below does this)

RE:

Where "cat" would be like the allowed string value, without it being the default value.

The advantage of the current default value syntax is that it works well when not "passing through" a value. So when you just write my_var = type String | 'igloo' anywhere in your code then it feels natural that 'igloo' is the value you're assigning to my_var, as no arg is being passed through. The default value is still validated against the union types, so it's tight, for want of a better word. I'd like to keep the syntax for that reason. I hope others agree with me on this? It really was just an experiment I made 2 months ago that stuck

[maedi]

OK one more idea:

# Method definition:
def my_method(my_var: Enum["red" | "orange" | "yellow"] | "blue")
# Local definition:
my_var = type Enum["red" | "orange" | "yellow"] | "blue"

Or:

# Method definition:
def my_method(my_var: Enum["red", "orange", "yellow"] | "blue")
# Local definition:
my_var = type Enum["red", "orange", "yellow"] | "blue"

[caifara]

Personally, I'd argue that a type system should be able to express all possible method intents ruby makes possible. It would feel like a waste if some methods couldn't be typed by definition.

If I follow correctly, building on your last example, a method accepting a single word as possible argument, but not setting a default value would be defined as:

def my_method(my_var: Enum["red"])

I don't know if that is the perfect syntax, but it would allow defining the possible argument w/o defining the default value at the same time.

[maedi]

Yeah, that example is how we'd do it without a default value. The default value is optional

[davidcelis]

Based on your original question of "if | means 'or' then what means 'one of'?", I think your second option in that comment from a few days ago makes the most sense to me:

# Method definition:
def my_method(my_var: Enum["red", "orange", "yellow"] | "blue")

# Local definition:
my_var = type Enum["red", "orange", "yellow"] | "blue"

The first option in that same comment looks okay but I worry it starts to overload what | is used for… My question with either of these, though, would be: should providing "blue" as a default with those enums be considered invalid? Or should it automatically add "blue" to the enum's list of acceptable values? I kind of feel like enums should be explicit and include "blue" in the list if its provided as a default but I guess it depends on how much magic low_type aims to handle

[maedi]

I worry it starts to overload what | is used for

Yeah, it starts to look a little weird and luckily I think I can think of a logical reason why; pipes seperate type expressions. If enums represents allowed values then they aren’t type expressions… the Enum is the type expression and the values are more like configuration for this particular type expression. I think that logic is non-conflicting.

For example:

my_var = type Array[String | Integer | nil] | "blue"

...represents an array that can contain any of these types.

Then:

my_var = type Array[Enum["yellow", "blue"] | Integer | nil] | "blue"

...would make sense, as | "blue" matches the enum value of "blue", you don't even have to add String as we're already passing on the enum value of "blue".

But this wouldn't make sense or be useful:

my_var = type Array[Enum[String | Symbol] | Integer | nil] | "blue"

...we want an enum to narrow down our options from a list of values, not do what union types usually do. Above would be equivalent to the simpler:

my_var = type Array[String | Symbol | Integer | nil] | "blue"

And:

my_var = type Enum[String | Symbol] | "blue"

...would be equivalent to:

my_var = type String | Symbol | "blue"

Another advantage of Enum["yellow", "blue"] is that you could splat a large array of values into it.

[maedi]

should providing "blue" as a default with those enums be considered invalid?

I think the default value should always be validated against the type expressions to its left for consistency, and for peace of mind. If you define the types then you know the value or default value will always be that type.

Think of a situation where you don't have as much control over the default value:

my_var = type MyType | fetch_my_object(id: 123)

...here you would want the assurance that fetch_my_object(id: 123) is being type checked.

Another example is:

@my_enum = Enum["yellow", "blue"]
# Lots of code in between
my_var = type @my_enum | "red"

...in this context you really are asking "red" to be validated against @my_enum.

[davidcelis]

agreed!