Thanks! And just to see what it looked like/for anyone following along at home and still interested despite all the consensus against this, I went and added (in PR) a struct with access behavior not relying on the atom lookup hack… First pass at a struct with Access behavior by bglusman · Pull Request #2 · bglusman/indifferent_access · GitHub (EDIT - and then for the hell of it, more config, merged, and new published version, because, I dunno, it took 5 mins and let’s people play with it all… Occurs to me the approaches are hard to compare because the struct approach at least currently only changes top level hash in params, but I suppose when getting a value that’s a map it could wrap it in a new param struct making it sort of lazily recursive/allowing get_in to work at > 1 depth… Maybe I’ll do that or make that another config just for fun! 
)
bglusman
NobbZ
Exactly.
When I get input from the user, its usually that I validate it and typeconvert to elixir types as necessary. Then its either used for funcalls directly as bare value, or to create some other data. For what I have done so far, this other data is about 90% some struct that existed already before I decided to get some user input.
And in case of projects using ecto, well, at least 50% of them have a schema and a changeset function which makes validation/normalization very easy and straightforward.
Of course, sometimes other data structures make sense, then use it. And of course, if there are user provided relationships, just don’t use atom keys. But either way, deeper in your codebase nothing should access a map by a literal string, as either you know upfront what you expect or you don’t. And if you use a literal string, it feels as if you knew what you should get, but forgot to normalize. (And as always, there are exceptions to this “rule”, case by case)
bglusman
Also released iteration this morning (only took another 10-20 mins so why not) to add option/default for the recursive wrap support to the Params struct… Haven’t tried in my project yet but welcome feedback! This may be more what you had in mind @mhanberg and I think I agree this is a better direction but the old options are still there also.
OvermindDL1
Heh, it’s like Protocols in elixir, but instead of working on a few limited set of types it works on matchers instead, so it can be exceedingly complex. It supports @priority definitions for matching order, testing callbacks (so you can enforce that things that implement a behaviour follow your contracts at compile-time), etc… etc… Lot of useful features that I’ve kept adding for my own use and a couple by request of others. 
If anything you’d want to keep the strings, not the atoms. Converting strings to atoms can be quite costly since they are never GC’d.
<soapbox>
PROPER STATIC TYPE SYSTEMS!
</soapbox>
/me coughs
^.^
I think its mostly a ‘can it be done’ kind of thing, not a ‘should’, a lot of my play projects are just ‘seeing if I can’ too after all. ^.^
ProtocolEx started out as that, just a ‘see if I can’ replacement of Protocol fixing all the faults that I saw in Protocol, it is one of the things that ended up being rather generically useful that I actually do use.
This this, structs are as close as we get to static typing in Elixir.
+1
I still say this is significantly false, at least for me it makes refactoring and feature development easier and faster as it is much easier to catch the places where things need to be updated.
Same thing in OCaml, it’s considered as being super fast and flexible to iterate/change while being safe about it. Rust is pretty easy to do this in as well though its syntax slows that down a good bit in ways that OCaml doesn’t (but once you ‘get’ Rust it is near as fast, though ‘getting’ rust can be a large hurdle for a lot of people due to how different it is from other things).
I really wish it did. I wish it was a struct of GET params, POST/field params, and arguments from the path, in addition to perhaps another field for plugs to inject things in to.
Soooo much this. Easily 95%+ of my errors in my Elixir apps are things that would have been caught by a static typing system before a compilation ever completed successfully and I wish it did. Sure tests catch things but you have to know ‘what’ to catch, and there is so much a typing system will catch just automatically, definitely not everything but easily that 95% of ‘stuff’ (at least my stuff).
Definitely for me. In C++, OCaml, Rust, etc… the number of times a compile failed and it’s something that Elixir or Python or so would have just let go through to crash at runtime is astounding. I don’t feel reliable coding with Elixir. I feel reliable on the BEAM in the ways its designed, but Erlang/Elixir-the-language I feel like I fight with way too much.
Uh, PHP has a static type system for a while now too. It can give quite a performance boost in addition to the compile-time safety it adds. ^.^
/me still has to deal with PHP for people at times, it’s not near as bad as it used to be…
Yeah I would not be happy with that either. In OCaml to just ‘Get a feature in now’ kind of thing I can scatter failwith "blah" all over the place, that will make the type system happy (it returns ‘anything’, since it crashes instead of returning) and it is super easy to grep for (make the CI not allow it in production builds for example). Scala has the ??? operator for that, C++ has all kinds of ways to die, Rust has panic!(...), etc… There are ways to ‘make the type system happy’ but in a safe way that you can force not to be allowed in prod builds in every strongly typed language that I know that makes iterative development really fast and yet still significantly safer.
Eh, except right now phoenix is kind of ‘munging’ multiple parameter types together. Like just from mind if a field named id is passed in via a GET, a POST, and a router argument (and who knows from what else) or in any combination thereof, then what gets priority, which gets set in this mapping? This is why they should be distinct, they should not be ‘combined’ into one map, that was such a huge PHP error and vulnerability for such a long time that they finally got rid of in like PHP5 or so (though thankfully the routes themselves help ‘clean’ it a bit compared to the PHP horrors, lol).
Likewise, it’s best to think through ideas by debating for each side of the debate. ^.^
I entirely agree with this, at least for my most common class of bugs by far static typing makes impossible just by virtue of how they work (assuming you don’t start stringly-typing everything or so ^.^;).
Eh, it’s still fun to make things just to make them though. ^.^
GraphQL and Absinthe are awesome. ^.^
You can make a new Access function that can be used in things like get_in and so forth to do indifferent access, I think one of the other libraries has one.
“option/default”?
bglusman
Yup! I’ve looked at a few times when browsing your github, just never found/remembered a good excuse to play with yet.
Well, no, I never create atoms dynamically, as much as this may be for fun I wouldn’t want to create something that added actual attack vulnerability. I guess you didn’t look at the code, but it gets initialized with a map of all atoms in system keyed by string so it only ever replaces strings that already have a corresponding atom.
That’s the default behavior of the new version of the library, it converts params to an IndifferentAccess.Params struct with either recursive or static/flat behavior for maps pulled out as values. It also still supports two variants of the old behavior using the atoms_map. I doubt I’ll ever actually use it myself but I think the result is fun and maybe reasonable for some people to use! Maybe we can extend it with your idea for seperate area for different actions or something, I can’t quite visualize that but it sounds interesting, but might not belong in the same library.
OvermindDL1
bglusman
Well, yes but it errors if it doesn’t exist, I don’t want to rescue, I just leave the string in place in that case.
OvermindDL1
Heh, well it will use a lot less memory, plus it’s missing something big:
Atoms can be dynamically added, which is very common as modules are loaded into the running system, so when the atom list is captured may be very incomplete until ‘later’.
So rescue’ing is better, just wrap it in a wrapper function. ^.^
bglusman
True, but thats an acknowledged limitation… though I suppose that might be a good additional option that wouldn’t require the option_map, but different time/space complexity tradeoffs, the overhead of rescuing when wrong is a lot higher than nil map lookup but agree its more reliable and less memory intensive… 
nothing wrong with either but there’s some overhead for using this and didn’t want ti to be too terrible but maybe that’s the new third config option!
