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

Add new practice exercise bank-account #708

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

jiegillet
Copy link
Contributor

This is week 41 of 48in24.

This exercise is not straightforward, there are different ways it could be approached. Here are some notes:

  • It is suggested that it's a good one for testing concurrency, but Elm can't do that on Exercism (since we need Task and a way to test them) so I did not implement the last test related to concurrency.
  • In some languages, a stateful approach could be taken (a bank account is created and can be accessed by different clients), but we can't do that in pure Elm either.
  • The way I would write this API in real life would be different, I would consider phantom types to only allow operations on accounts that are open. The problem with this approach is that it would get rid of a lot of tests that check for errors, and there are no way of looking at types with tests. We could do it with the analyzer, but that would be pretty unorthodox, and would require additional instructions. Doable though.
  • There were two tests that checked that an account not opened could not be closed, but that just doesn't make sense in a typed language so I did not implement them.
  • The API for the open function is quite unnatural, I wrote it this way to preserve as many test cases as possible and keep the spirit of the exercise as much as possible.
  • I'm very happy that this exercise is suitable to be our first one to practice the opaque-types concept, since we don't even need to export the type.

I'm happy to discuss or revisit all of these decisions. The code is very simple, but the API is not.

@mpizenberg
Copy link
Member

I just had a quick look and didn't find anything shocking with the code. But I don't know much of the context and objectives of the exercise regarding concurrency.

@jiegillet
Copy link
Contributor Author

The code is fine, it's quite simple, it's the API (function signatures) that could be built differently.
The canonical data is a bit vague with it's "operations".
The last test is the one talking about concurrency.

@jiegillet
Copy link
Contributor Author

@mpizenberg @ceddlyburge
I know that my description was long, but really if you don't have concerns, I'm fine with the exercise as it is. In a nutshell:

  • we don't have concurrency, but that's not a requirement, so it's not an issue
  • the API could be different, but this version allowed to keep the most exercises

@ceddlyburge
Copy link
Contributor

Hi @jiegillet , I left this to matthieu as he got their first, but if he doesn't get back to you in a few days I'll take a look

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

Successfully merging this pull request may close these issues.

3 participants