Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Renaming the Decodable protocol #474

Open
gfontenot opened this issue Sep 30, 2017 · 0 comments
Open

RFC: Renaming the Decodable protocol #474

gfontenot opened this issue Sep 30, 2017 · 0 comments

Comments

@gfontenot
Copy link
Collaborator

gfontenot commented Sep 30, 2017

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.

related: #466, #471

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant