-
Notifications
You must be signed in to change notification settings - Fork 37
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
Add a :type_spec
option
#120
Conversation
Pull Request Test Coverage Report for Build 44c00153f8d848fcfc5fb171e9d9b8fbc713b8a6-PR-120
💛 - Coveralls |
I think once we start adding quoted expressions, we are probably already doing too much. So I am |
@josevalim the repetition if you have to do this yourself is quite a bit. For example, I have a schema with ~20 options, and I only need to customize the type spec of a couple of those. Given the amount of code this adds to nimble_options, and given this is (I think?) the only thing left that you can't do with this library, I think this makes sense as an addition. |
The issue is that it comes with downsides. For example, you can't add docs to the types themselves. And when clicking to go to source, it will point to a meta-programmed source. Sharing types require going back to usual types instead of using this option. Etc. So I can easily see this cascading into a bunch of options and controls to customize code generation, or lead into an inconsistent style where some types are written in NimbleOptions, and others aren't. This will be more inconsistent than consistent. |
I’m not sure what you mean here @josevalim, sorry 😬 Since we have |
Gah, I forgot about |
@josevalim you mean that |
I don’t see the benefit of keeping type_doc around. It is an inferior version of type_spec which does not generate the correct spec. |
@josevalim ah, yeah! You're totally right. I shall update this PR to deprecate |
@josevalim no, wait. Edit. Take this case: nodes: [
type_doc: "list of `t:String.t/0`",
type_spec: quote(do: [String.t()])
] If we want to auto-generate a type doc from |
Gah. Alright, let's have this in, but to me this is the last step on the slippery-slope of typespecs in NimbleOptions. :D If we need further customization, i would rather yank the whole typespec generation out. |
@josevalim deal 😉 Slippery slope indeed, I’m kind of wishing we didn't have |
I'd love to have this for a bunch of use cases (mostly
{:custom, ...}
types). Thoughts?