<FromGitter>
<tenebrousedge> my recollection was that all metaprogramming was based on strings, like your examples
<FromGitter>
<Blacksmoke16> what is `String` tho, i get an undefined constant
duane has joined #crystal-lang
<FromGitter>
<tenebrousedge> well exactly
<FromGitter>
<Blacksmoke16> You can do like `MyClass::class` which is similar to crystal's `MyClass.class` however in PHP it just returns the FQN of the class vs a diff type
<FromGitter>
<tenebrousedge> right, it's all string-based
<FromGitter>
<absolutejam_gitlab> @tenebrousedge I wasn't trying to do anything, I just discovered go's `buildmode=plugin` and I was thinking about this kind of thing before as a way of extending Crystal apps without recompiling the world
<FromGitter>
<absolutejam_gitlab> just curious
<FromGitter>
<absolutejam_gitlab> haven't written any Crystal or been active here in forever, just want a reason to write some Crystal :[
<FromGitter>
<absolutejam_gitlab> @Blacksmoke16 I'm a fan of code configuration if it's appropriate
<FromGitter>
<absolutejam_gitlab> like, if you're configuring the app, why not utilise the app to configure itself
<FromGitter>
<absolutejam_gitlab> or laravel uses config PHP files, etc.
<FromGitter>
<absolutejam_gitlab> But then on the flip side, I think something like Wordpress shouldn't use `wp-config.php`, but should use yaml
<FromGitter>
<absolutejam_gitlab> or just be incinerated altogether
<FromGitter>
<Blacksmoke16> yea for sure
<FromGitter>
<Blacksmoke16> main usage would be for like CORs
<FromGitter>
<Blacksmoke16> or like global app settings, like `logs_dir`, default charset etc
<FromGitter>
<absolutejam_gitlab> if you're doing for a framework, then in-app
<FromGitter>
<Blacksmoke16> eventually want to get to the point where you define parameters, then use the parameters in the config as well
<FromGitter>
<absolutejam_gitlab> if it's a binary that you just consume, then yaml
<FromGitter>
<Blacksmoke16> hmm good point
<FromGitter>
<Blacksmoke16> it would be kinda annoying to have to ship your binary with a yaml file...
<FromGitter>
<absolutejam_gitlab> just dump out a default one or use defaults and make it optional
<FromGitter>
<Blacksmoke16> at that point whats the point of having the file?
<FromGitter>
<absolutejam_gitlab> well you ship it with sane defaults
<FromGitter>
<absolutejam_gitlab> and let people override
<FromGitter>
<Blacksmoke16> i guess what im trying to get at is, is it bad to have to ship a yaml file with your binary
<FromGitter>
<Blacksmoke16> that controls those overridden settings
<FromGitter>
<Blacksmoke16> vs having that in the binary and it configures itself
<FromGitter>
<Blacksmoke16> based on ENV vars or what have you
<FromGitter>
<absolutejam_gitlab> it depends whether your app is something highly reusable or if it's going to be configured at build
<FromGitter>
<absolutejam_gitlab> like, if it's your business app that gets deployed with highly specific business config, I'd say you manage it in-app/talk to services like consul
<FromGitter>
<Blacksmoke16> use case would be for athena ofc
<FromGitter>
<Blacksmoke16> which i cant imagine people changing the settings once its running
<FromGitter>
<absolutejam_gitlab> or if it's something highly generic like hugo, consul, etc. that you configure with the CLI, env, etc. then I'd say config file(s)
<FromGitter>
<absolutejam_gitlab> Yeah, I'd say in-app
<FromGitter>
<Blacksmoke16> that makes things a lot easier as well...
<FromGitter>
<Blacksmoke16> still going to make a PR for custom yaml tags, think that would be cool :P
<FromGitter>
<absolutejam_gitlab> like our production Laravel app, we have 20+ config files that all call out to env (and in prod we use Consul-template), and eventhough you can change things on the fly, we ship it as a docker image so it's essentially a 'binary'
<FromGitter>
<absolutejam_gitlab> whereas if I use something off the shelf like Consul, Influxdb, whatever, then I'd often supply a config file and env vars to configure it
<FromGitter>
<absolutejam_gitlab> because I'm just consuming it, not using it as a framework
<FromGitter>
<absolutejam_gitlab> and our production Laravel app is our website, it's not something like Snipe-IT where people will build upon it/consume it
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<Blacksmoke16> in-app deff seems the way to go for this case