Closed fedoracoreuser closed 9 months ago
I'm not sure I understand what's the advantage over using something like the json_map
helper from Jason.Helpers
or passing a map directly to Jason.encode!
. Can you explain a bit more about the use case?
Well, we have a very large test suite where we have a lot of round trips to and from JSON. In our particular use case, I found that having these sigils removed a lot of clutter, so I thought it would be nice to contribute them back to source. For example, we moved some tests away from BDD using cucumber that were using a JSON payload and back to regular ExUnit tests, and we had quite a few Jason.encode!
and Jason.decode!
invocations. We found that using ~j
and ~e
would make it more readable.
Apologies but I don't see the benefit of this approach either. Moving the parsing of Elixir code to the sigil means any error/warning coming from the sigil won't have the proper line/column information in error messages. If conciseness is important, I would define a function called j
that does encoding and call it like this:
j(%{foo: 321})
It would be even fewer characters than the sigil, but with good error messages, editor support, etc. :)
Hi, thank you for chiming in on this. I understand the points you've made and they are, indeed, valid. Closing. Thanks again!
We use sigils like these internally, for convenience. Maybe others would also find them useful. I tried to match the requirements of the other sigils, let me know if I need to add more tests.