Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:24
    straight-shoota closed #13014
  • 02:34
    Blacksmoke16 labeled #13023
  • 02:19
    cyangle labeled #13023
  • 02:19
    cyangle opened #13023
  • 00:41
    devnote-dev labeled #13022
  • 00:41
    devnote-dev opened #13022
  • Jan 27 23:05
    straight-shoota labeled #13021
  • Jan 27 23:05
    straight-shoota labeled #13021
  • Jan 27 23:05
    straight-shoota labeled #13021
  • Jan 27 23:05
    straight-shoota labeled #13021
  • Jan 27 23:05
    straight-shoota opened #13021
  • Jan 27 22:40
    straight-shoota labeled #13020
  • Jan 27 22:40
    straight-shoota labeled #13020
  • Jan 27 22:40
    straight-shoota labeled #13020
  • Jan 27 22:40
    straight-shoota opened #13020
  • Jan 27 21:18
    stefandd edited #13018
  • Jan 27 20:46
    etra0 review_requested #13006
  • Jan 27 18:30
    Blacksmoke16 closed #13007
  • Jan 27 18:30
    Blacksmoke16 closed #13019
  • Jan 27 18:21
    wyhaines closed #13019
manveru
@manveru:matrix.org
[m]
i basically want to write something like this:
struct Nomad::Config
  include SimpleConfig::Configuration

  options_from Common::Config, nomad_datacenters, nomad_base_url, nomad_ssl_ca, nomad_ssl_key, nomad_ssl_cert
end
and look up the types in Common::Config for each of the attributes, and generate a typesafe constructor for it
George Dietrich
@Blacksmoke16
yea idt you can do that
manveru
@manveru:matrix.org
[m]
i'm not sure how that'd work as a method
George Dietrich
@Blacksmoke16
wont be able to iterate the ivars within a method, and you of cant create a method while you're in a method
just manually create the constructor
or use a macro to generate it if you really want
manveru
@manveru:matrix.org
[m]
yeah... a macro doesn't really give much in this case then :)
George Dietrich
@Blacksmoke16
you could do like def_constructor nomad_base_url : URI, ...
manveru
@manveru:matrix.org
[m]
sure, but def initialize(@nomad_base_url : URI) is pretty much the same and less confusing
George Dietrich
@Blacksmoke16
exactly :)
this is a case of macro over complicating something that is simple
manveru
@manveru:matrix.org
[m]
i'm mostly exploring macros at this point, so was just wondering how recursive it can get :)
George Dietrich
@Blacksmoke16
I think there's away you can get this to work, but it's not recommended, give me a sec
manveru
@manveru:matrix.org
[m]
i could generate Nomad::Config when creating Common::Config though, that should cause less problems i think
George Dietrich
@Blacksmoke16
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")
manveru
@manveru:matrix.org
[m]
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
George Dietrich
@Blacksmoke16
hm?
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
manveru
@manveru:matrix.org
[m]
yeah
i'll try one other idea i just had though
George Dietrich
@Blacksmoke16
Mmk
manveru
@manveru:matrix.org
[m]
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 :)
George Dietrich
@Blacksmoke16
Fwiw, constructors are inherited
manveru
@manveru:matrix.org
[m]
yeah
George Dietrich
@Blacksmoke16
:ok_hand:
manveru
@manveru:matrix.org
[m]
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...
George Dietrich
@Blacksmoke16
Are these like config values, or like unique types
manveru
@manveru:matrix.org
[m]
mostly configs
should be immutable after initial parsing
George Dietrich
@Blacksmoke16
Have you considered passing in a single config obj versus specific values?
manveru
@manveru:matrix.org
[m]
yeah
but that means i'd need to make the value types either optional, or use totally wrong default values...
George Dietrich
@Blacksmoke16
How so?
manveru
@manveru:matrix.org
[m]
or the user has to pass 50 options even if that command would only need 2 or so
George Dietrich
@Blacksmoke16
How are the values provided?
manveru
@manveru:matrix.org
[m]
either config file, cli flags, url params, default values, or env vars
George Dietrich
@Blacksmoke16
Gotcha
manveru
@manveru:matrix.org
[m]
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...
George Dietrich
@Blacksmoke16
You could use lazy getters maybe
manveru
@manveru:matrix.org
[m]
at that point it may fail at runtime, which also sucks