The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
so... method overloading on works for argument and not return types?
why?
def convert(value : String) : Array(String) instead of def convert(value : String, kind : Array(String).class)
i guess it could look at each overload's return type and compare that to something? :shrug:
well, i have a bunch of those that take a string and return some other type
given that crystal already infers the return type, and it knows what type i want to assign to a given instance variable, i was hoping there was a way to elide that annoation
anyway, just got my code to pass a bunch of tests, here's what i got: https://gist.github.com/manveru/5050af58be7e36bbc9d116eb5d8eccba
maybe you can suggest some other ways to do this better :)
so to add other conversions, you'd add another
convert method to Test::Configuration instead of having them infect all other types... i guess i'm still thinking functional
for json/yaml it makes more sense, since they're already in stdlib anyway
is what i would do
it's not going to harm anything, as you're not messing with the state of the internal obj or anything
can get complicated if you need to support like
Int32 | Bool | String tho
i tried a bunch of existing ones, but none really fit my use-case...
well, habitat was nice, but it assumes you configure all via crystal, envy/envyable are yaml, totem was probably the closest to what i wanted i think
but i wanted flag generation for optionparser and special handling for file paths passed as option values, since they're usually files containing secrets that i'd like to encapsulate and avoid accidental leaking of
plus it had no idea of how to handle URIs and the types it handles are not extendable afaict
there's als ohttps://athenaframework.org/components/config/. technically it's not coupled with the rest of athena. but not sure how useful it would be in your context. I.e. if you need to support runtime alteration of the values as it doesn't support that atm
does support alternate instantiation methods, e.g. from a file but meh
I'm curious how Crystal handles the once-only evaluation problem with macros, but that may be a question for the forums/someone experienced with macros not limited to the Crystal subset of the concept.
Well, I know very little about Crystal macros but consider you wanted to write a
square() macro, that takes 1 argument and multiplies it by itself. Because macros take in AST nodes and output AST nodes, and are expanded before the semantic analysis, such an invocation could be: x = 4; square(x += 1), which would expand into code that basically does (x+=1) * (x+=1), that is, the side effect of incrementing x is evaluated before the second occurence of x is evaluated, giving a wrong answer. I'm not sure if I explained that well enough...
they're mainly just ways to generate crystal code
and this was a bad example, only for demonstration purposes. Clearly this should be a method, not a macro :)
Right. Macros are strictly for 2 things only.
But this problem comes up a lot in unhygienic macro systems, which CL and Crystal have afaict.
Unhygienic meaning that the the lexical state of the macro expansion can leak into the call site
Usually generating a temporary variable that is guaranteed to be unique is the way to solve this, which I see Crystal can do
which can be quite helpful, when you also bring unique indexes into things