Crystal: Socket::Family and friends should not be enums

[stronny]

https://forum.crystal-lang.org/t/af-netlink/861

These things are not enums in C so they shouldn’t be enums in Crystal, exactly because their values shouldn’t be a fixed set (new types could be added in the future and we don’t want to fix the std to a fixed set).

(just turn those enum members into constants)

[asterite]

Thinking a bit more about this, we should just add the missing values. No need to introduce a huge refactor.

[straight-shoota]

Also, enums can always be reopened and extended (in a shard for example).

[asterite]

@straight-shoota You are back! ❤️

Unfortunately enums can't be reopened... the reason is that enums are closed by design. If you could reopen and add more members then you would be breaking existing code that doesn't handle those new members.

[straight-shoota]

Oh, I was sure I had seen this working somewhere. But yeah, my mistake it doesn't work.

[stronny]

What does work is this:

enum Test
  TEST
end

def test(v : Test) : Nil; p [v, v.value, typeof(v)] end

test Test::TEST
test Test.new(200)

I think you are overtyping so to say, but I agree that a large refactor is probably not worth it.

[asterite]

Oh, yeah, you can always create an enum with any int value, so I think that's a good-enough workaround for now.

[stronny]

I mean yeah, it lets you escape enum limits, but doesn't it go against your intentions? Would you consider this behaviour working as designed or rather an oversight?

[asterite]

Would you consider this behaviour working as designed or rather an oversight?

I think... both (seriously). I mean, I think it's good to restrict the possible values. But it's also good that there's an escape hatch for cases like this.

[asterite]

My ideal solution would be to add the missing enum values to the code. But I don't have time to find those values and send a PR right now. But PRs are welcome as always!