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

Units: Use use to simplify implementing units #155

Open
PragTob opened this issue Oct 21, 2017 · 1 comment
Open

Units: Use use to simplify implementing units #155

PragTob opened this issue Oct 21, 2017 · 1 comment

Comments

@PragTob
Copy link
Member

PragTob commented Oct 21, 2017

The unit implementations have a lot of method definitions that an implementation needs to define but that definitely just call out to a more common for code sharing.

For instance:

  def scale(count, unit) do
    Scale.scale count, unit, __MODULE__
  end

if we implemented that functionality inside a __using__ definitions of those functions are unnecessary, leading to more concise unit definitions. A smaller example of this is implemented in #154

genserver does the same - well more or less. Difference is, we don't want the functions to be overridden as far as I can tell.

Downsides of this approach I see so far:

  • magic 🌟
  • I think the documenation of the methods that are defined "commonly" will be the same for all modules. Not really a "big" problem, but that means the iex usage examples/doctests will always contain examples of the other units (or none at all)

I think it should considerably shrink down the effort to implement new units so I think it'd be good. Interested to see what others think ( @wasnotrice since you did the first version here)

Not high priority, as it'd be pure refactoring

@wasnotrice
Copy link
Collaborator

@PragTob I agree this would be nice. It did bother me when writing this that there was so much boilerplate to write in order to add a new unit.

I agree we may lose some doctests, but maybe that means we write different/better ones!

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

2 participants