RFC: Renaming the Decodable protocol
gfontenot opened this issue · 0 comments
I've finally gotten some time to work on this, and I'd like to push forward with solving the naming conflict between Swift.Decodable and Argo.Decodable. I've also opened up #473 to rename JSON to Value.
I'd like to get thoughts from people on the naming of the Decodable protocol. I'm not sure that I have super strong opinions on what to name it, and I'd be willing to bet other people do.
Prior Art
One quick data point that we can probably immediately disregard:
Aeson calls their version of Decodable FromJSON. Their decode function is then called fromJSON. I think that given our move away from using JSON in our naming, it doesn't make sense to follow their lead here.
Proposal: WeakTypeConvertable
One idea I keep coming back to is the idea that (from a marketing standpoint) we can push this idea of moving from weak -> strong data types via the protocol. This isn't nearly as catchy a name as Decodable (or even FromJSON), but it seems to be more descriptive. An interface for this might look like:
public protocol WeakTypeConvertable {
associatedtype TargetType = Self
static func decode(_ value: Value) -> Decoded<TargetType>
}The one thing (other than the clumsiness of the overall name) I don't like is that it feels like this pulls me down a rabbit hole for the function/result names. It seems to me that we might want to move all the way to something more like:
public protocol WeakTypeConvertable {
associatedtype TargetType = Self
static func fromValue(_ value: Value) -> Converted<TargetType>
}It's not too difficult to see how this can start to spiral into a much larger rename where we touch every part of the lib. I'd imagine this level of change would be incredibly painful for end users.
I'd love to hear thoughts on this from people that have a vested interest in the end result.