Support more Literal types in JSON::Serializable's use_json_discriminator macro

[voximity]

This PR supports the following Literal types as keys for hashes passed to use_json_discriminator:

• StringLiteral
• NumberLiteral
• BoolLiteral
• Path

This allows more types to be expected from a discriminator value. Previously, use_json_discriminator was hard-coded to expect a string value. String, boolean, and integer values are now supported. An example:

require "json"

enum Shapes
  Point
  Circle
end

class Shape
  include JSON::Serializable

  use_json_discriminator "type", {Shapes::Point => Point, Shapes::Circle => Circle}
end

class Point < Shape
end

class Point < Circle
end

Shape.from_json %({"type": 0}) # a Point
Shape.from_json %({"type": 1}) # a Circle

[asterite]

Thank you!

Do you have an example API in mind where this can be useful?

[voximity]

@asterite My specific use case is discriminating Channel objects from Discord's API into their respective types. Discord uses integer enums explicitly to describe object types. I tried implementing an enum similar to the example I give in the original comment, but the old implementation expects a string over an integer for the field value.

Implementing Path and NumberLiteral fixes this, but I also added BoolLiteral as it's easy to support, and perhaps one day there'll be some API that decides discriminating object types by a boolean field is necessary!

[asterite]

Strange, I think enum should support deserialization from int and string, instead of this PR.

[voximity]

The main issue is that previously discriminator_value was always fetched by pull.read_string, but the value is not always a string.

[asterite]

Oooooh... got it! Sorry, I should have looked at the link you sent, I was on mobile.

Yeah, it makes perfect sense then. 🙏

[asterite]

I think key.id.stringify is just key?

[voximity]

Oh, you're right! I just kept it this way because I was looking at the NamedTupleLiteral stringification.

[caspiano]

pardon my asking @bcardiff, but is this going in 1.0.0?

[Blacksmoke16]

Probably should do this for YAML too no?

[voximity]

Probably. Didn't think of it/need it when I opened this PR. I may get around to it in some time.

[bcardiff]

Sorry, this felt out of my radar so far.
Looks good. I have an optional comment for completeness.

It needs a rebase, but I am ok to include for 1.0

[bcardiff]

I guess we don't need Float64 here, but it seems the atomic values of JSON::Any are wanted here, except for Float64

[straight-shoota]

This variable really doesn't need any type restrictions at all.