Isn’t it obvious? Plug.Conn is a struct and parameters have to be a bare map because every app has their own set of parameters incoming to their controllers.
dimitarvp
0
bglusman
Well, yes, that may have been a bit of a brainfart/rushed thought… I think I was trying to make a point about how you can’t always use structs perhaps if you have an unknown set of keys, and our app is very dynamic/there are quite a few varieties of user configurations and settings coming stored in Postgres jsonb columns with customization for each different client…
(EDIT- I guess I was thinking/could argue hypothetically it could have been/could be a struct with an underlying map that has access behavior to access that map, and thats another version of this library I’m still considering trying out, that does approximately that to make an IndifferentParams struct that stores a map as basically its only value and uses access behavior to access that with atoms and wouldn’t care whether the atom exists, would just to_string the atom to look up, or fall back on to_string if the atom key is nil or something)
I don’t mean to seem argumentative/I’m not sure how much of what you or others are saying I disagree with at all, but playing devil’s advocate is part of how I figure out what I really think, so thank you for indulging me/apologies if the writing has come across the wrong way, it’s always a challenge to manage/understand tone both in the writing and in the reading. I appreciate and probably agree with you and most others here, but I threw this out there knowing more or less what most of the reactions would be, but wanting to try and play out and see if I was surprised by any or the points I or others made in either direction.
0
bglusman
The PR I referenced above I think makes the library “only” do this, and I’m inclined to dismiss that version of it a little less than the original/I may spend 20 minutes trying that version out in my app to see how current behavior/test-failure situation compares… but I think I somehow didn’t do a good enough job communicating that nothing about the initial version I linked to was remotely finalized, it doesn’t have a single test, it was just a concrete direction (incorporating someones non-rescue based check for atom existence) to think about/discuss/consider more-or-less automated ways to not have to rely on strings in params maps.
0
dimitarvp
I think your initial message was quite clear but the people around here definitely get PTSD and nightmares by such patterns. 
As a feedback, ultimately I parsed two things from your comments here:
-
You are kind of afraid of big refactorings. My opinion: you should not be. Refactoring your code to be stricter and less surprising is always worth it. If you really don’t have the time now, do your backlog features and keep taking notes for when you eventually get around to the refactoring (also chat with your employer; you are not a factory worker, programming is a creative job). Don’t try to cheat your way out with minimal work; well-behaved code requires focused and exhausting effort.
-
You are questioning the benefits of stronger typing / compile time errors. Nobody can convince you otherwise if you feel strongly about it but have in mind that languages like OCaml and Rust make an entire class of bugs impossible by the mere virtue of your program compiling successfully. We don’t have that in Elixir and we’re trying to gain some of it any way we can. If you value the mega-quick-time-to-working-MVP more then you probably shouldn’t use Elixir or push your team to move away from it.
1
bglusman
Sorry I didn’t put a trigger warning on it!
(also note I edited above briefly while you were replying)
I both am and am-not afraid of larger refactoring in different senses; I have done large refactorings successfully, but I do like playing around with different approaches/alternatives and have occasionally had a refactoring that passed all the tests and code reviews and seemed like a pure refactor every step of the way and still caused a bug in production for one reason or another. I like to think of it as a healthy fear, it won’t stop me from doing it, but I have respect for working code also and awareness that no amount of tests can prove the absence of bugs! 
I think I push myself harder than my employer does, but there is certainly mutual agreement that though it’s OK to charge the tech debt credit card, there’s also need to pay it down afterwards to avoid excessive interest payments.
I don’t know that I question the benefits of static typing (Elixir is strongly typed) but I do recognize that it has tradeoffs. I’m very interested in @keathley 's upcoming design-by-contract project as a potential sweet spot for these trade-offs, and a lot of what he’s spoken about on Elixir Outlaw’s resonates with me… and I think he’s one of the few way-better-than-me programmers in the community I’ve also seen question the value and advantage of “structs everywhere” vs Bare maps, so I’d be curious to hear his thoughts here. (EDIT - I beleive he said Bleacher report, which has of course scaled elixir quite far and well, has only a handful of structs in their codebase, so it at least provides some high profile counter-evidence to the idea that structs are the answer)
I don’t know what to say on the last point, re: probably shouldn’t use Elixir, but I don’t understand it and don’t think you’re going to convince me not to use it
0
dimitarvp
You can do that. I can bet $20 that you’ll spend more time developing it now compared to the time you’ll save down the line by using it, though.
I don’t think this debate exists at all or that anyone says “structs are the answer” universally. Not sure if you noticed but most people in ElixirForum are refugees from other languages and frameworks, and a part of them still work with those or other languages but not Elixir. I feel the average quality of the programmers around here is pretty high and most would simply tell you “use bare maps vs. structs using your best judgement” which, yeah, is not a concrete advice, but then again you haven’t given much details yourself.
For what it’s worth, I’m only enforcing structs on controller params with a well-known and mandatory shape like pagination or ordering clauses. I do however convert string-keyed maps to atom-keyed maps very quickly and do exhaustive pattern matching when working with them further down. Getting FunctionClauseError gives you pretty clear error messages and I always go the extra mile to make all my function heads – including private ones – as strict as possible.
1
bglusman
You might well win that bet if I do it! Or rather, you could never win the bet because we never get to try things both ways (and especially not both-ways order independently!). But if I do it, it will not be to try and save the time but just to have a potentially fun thing to hack on as a side project/something without the time or other contraints from work, even if it was inspired by work or (maybe, but probably not TBH) winds up getting used there. In any case, happy to have chatted and appreciate your time and feedback. Sorry if I misrepresented your or other opinions above, I guess I was reacting to @NobbZ 's comment that
which didn’t sit entirely right with me/was perhaps the most concrete alternative I saw presented.
0
dimitarvp
I can’t talk for him but I believe he meant that “normalised data” is what I called above “data with a well-known and mandatory shape, like pagination and ordering clauses”.
Happy to oblige the chat.
1
GregMefford
“Mr. Keathley declines comment on this matter, except that he wishes to no longer be involved in this nonsense.” 
… but as someone else that works at Bleacher Report, I can say that structs aren’t required for scalability or anything like that. They’re just maps at the end of the day. It’s nice to be able to document and enforce the structure of things, like Plug.Conn does, when a lot of people need to collaborate on the same data structure. For your app code that’s changing all the time, it’s probably just as easy to use a map and try to keep it as simple as possible, at least until the code stabilized and you know what the “right” fields are going to be.
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe