[wip] [experimental] New type and converter for expandable fields

[ob-stripe]

Still very experimental, and the code is downright awful at the moment, but here's the gist of it:

• adds a new ExpandableField<> generic class used to replace the previous StringOrObject<>.Map method. The class is simply a container for two properties:
  • a string (Id)
  • an instance of the type param (ExpandedObject)
• adds an ExpandableFieldConverter custom converter class to deserialize ExpandableFields. The converter:
  • creates an instance of ExpandableField
  • if the JSON is a string, fills Id with the string and sets ExpandedObject to null
  • if the JSON is an object:
    • if the param type is an interface (i.e. if the type is a polymorphic resource), deserializes the JSON with the proper custom converter
    • if the param type is not an interface (i.e. it's a concrete class), directly deserializes the JSON into an instance of the type
    • sets ExpandableField to the deserialized instance and Id to the value of the Id property of the deserializes instance
    • if the deserialization fails for some reason (e.g. because of a new polymorphic type that the library doesn't know about), make a last attempt at manually extracting the id property of the raw JSON object
  • returns the filled ExpandableField instance

Sort of works, but we'll also need to add a custom deserializer for StripeList to handle polymorphic types there as well.

[remi-stripe]

Okay so in principle, I really like where this is going and I think it would work. I don't think the code is especially awful either.

Some feedback that might help

• I would love to see a test for serialization/deserialization to ensure this continues to work as devs expect
• I wonder if there's value in only ever supporting the Expanded object and not have the customer get/setter for the id/object. Basically do what we did in Go and less what we did in Java if that makes sense
• I'm curious how hard it will be to remember to changer the converter for future interfaces. Is it easy to add a test for this? If not, I worry that we really on tribal knowledge.

[ob-stripe]

I would love to see a test for serialization/deserialization to ensure this continues to work as devs expect

Yep, definitely on my TODO list.

I wonder if there's value in only ever supporting the Expanded object and not have the customer get/setter for the id/object. Basically do what we did in Go and less what we did in Java if that makes sense

I'm on the fence about this, I kind of like that those custom getters help keep a ~1:1 mapping between the library's class structure and the API's structure. If we only exposed the ExpandableField attribute that would add a virtual layer that only exists in the library. Not sure it's that big a deal though.

I'm curious how hard it will be to remember to changer the converter for future interfaces. Is it easy to add a test for this? If not, I worry that we really on tribal knowledge.

Not sure this is easily (or even hardly 😛) testable. I think it's on us to keep in mind that handling polymorphic resource is one of the more fragile parts of the library and we should write thorough tests when such resources are added. I'll see if I can come up with something automated though.

[ob-stripe]

Superseded by #1396.

(I might still introduce an ExpandableField<> generic in a future PR as I think it's cleaner than the existing StringOrObject<>.Map trick, but trying to minimize changes for now.)