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/
i'm mostly exploring macros at this point, so was just wondering how recursive it can get :)
i could generate Nomad::Config when creating Common::Config though, that should cause less problems i think
module Common::Config
CONFIGS = {} of _ => _
macro config(type_decl)
{% CONFIGS[type_decl.var.id] = type_decl %}
getter {{type_decl}}
end
config some_value : String
config some_id : Int32
end
macro options_from(type, *configs)
def initialize(
{% for config in configs %}
{% config = Common::Config::CONFIGS[config.id] %}
@{{config}},
{% end %}
); end
{{debug}}
end
struct Some::Config
options_from Common::Config, some_id, some_value
end
Some::Config.new 10, "foo" # => Some::Config(@some_id=10, @some_value="foo")
just trying to reduce the number of places to change when i change options, while giving sub-commands only the minimum set of options they need for easier testing and invocation, while avoiding accidental dependencies
oh, that is kinda cool :)
didn't know => was a thing
i will say, yes it works but im not a fan at all of this mutable concept approach
imo it still over complicates the process of just defining a constructor manually
i'll try one other idea i just had though
i think it'd be beneficial to encode the hierarchy in a single pass instead of throwing it all over the code
not sure if i'll like the result, but gotta try it anyway :)
atm i have for example a server that needs options [a,b,c], and it calls sub-components that require options [b] or [a,c], or [c,d] etc...
each sub-component can be called without the server, in which case you would only need to pass their specific options
so inheritance is a bit weird there...
should be immutable after initial parsing
but that means i'd need to make the value types either optional, or use totally wrong default values...
or the user has to pass 50 options even if that command would only need 2 or so
either config file, cli flags, url params, default values, or env vars
here's an older version of the actual code: https://github.com/input-output-hk/bitte-ci/blob/main/src/bitte_ci/config.cr
so that pass-the-full config approach is what i had before, and it sucked :)
when you wanna run db migrations, all you need is the db url, for example
but it will fail for not finding a github token...
Or really, maybe even getter! Would be sufficient here
@didactic-drunk: should we add Process.fork to crystal-posix? @kevinsjoberg was asking about lack of
Process.fork. https://gist.github.com/postmodern/a98e68dff96163b5f234cd9de1c5c75d
2 replies
I'm trying to solve a visibility issue.
I have private class method
I have private class method
self.foo at the module level in one file, and in another file I have a struct defined in the same module. I would like some of the instance methods of the struct to be able to use the private foo method at the module level, but I cannot fully qualify it, and it is not part of the struct so I'm not sure if this is possible. I'm trying to write a file of private helper methods that are used in several other files/structs
Cancel that. I seemed to have figured out the right incantation to extend the module with private methods according to
crystal doc.
@didactic-drunk @kevinsjoberg hmm nevermind, looks like
Process.fork does exist but is nodoc'ed / part of the private API. https://github.com/crystal-lang/crystal/blob/1.0.0/src/process.cr#L62-L98
@Blacksmoke16: Maybe, though I'm not sure what that means for module methods...the docs talk about instances. I found a way with private though.