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

Type casting #8

Open
bjuretic opened this issue May 7, 2018 · 0 comments
Open

Type casting #8

bjuretic opened this issue May 7, 2018 · 0 comments

Comments

@bjuretic
Copy link

bjuretic commented May 7, 2018

Hi,

more ideas:

1. How about you cast incoming data keys into atoms, if the user supplies some argument, like keys_to_atoms: true

The reason for this is that in the function (e.g. in some "service" layer in your code) you don't want to check all the time if the string or atom key exists, you just want to work with one of them. Jason and Poison have options for this, for example.

2. Casting to primitive types would be great. That would be something similar to what Ecto Changeset is doing. Because you already have the spec with the type specified there, basically only the implementation is missing, spec is fine. This can be a separate function of course so you don't break old versions.

The reason for this is that you typically want to have a separate controller/frontend layer which deals with HTTP etc. - and over there the params received will have string keys and string types (especially if sent as form encoded and not as JSON). You want the layer like skooma to normalize params so that you can handle only one case in your service layer.

For example age: :integer should turn up as params.age (integer type) and you can then easily do your business logic because:

  1. No messing around guessing key type (string or atom)
  2. You know that the data "structure" is valid
  3. You have the correct types so you can immediately work on them without transformations and checks, and catching errors for all that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant