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 will have to see how it is to be used and benchmark some I suppose. For now, they are structs though. I expect the change to class to be easy later if need be.
I'm having a ton of fun learning, albeit slow, thanks for your help :)
Do the property/getter/setter macros inline the generated method defs?
could you even inline that? like since its internal state
I guess it depends how they are implemented. In Lisp, struct members are regular functions that access the internal state, and are inlined by default, but can be told not to be.
I was just wondering if that was the case here, and if the
AlwaysInline annotation was implied, or a way to opt in/out
undefined macro method 'Path#instance_vars' confused me way longer than i wanna admit... it refers to Crystal::Macros::Path and not Path :P
?
macro derive_from(owner, *names)
\{% for name in names %}
\{% var = owner.resolve.instance_vars.find{ |v| v == name } %}
property \{{name}} : \{{var.type}}
\{% end %}
def initialize( \{{ names.map{ |n| "@#{n}".id }.join("").id }} )
end
\{% debug %}
end
the problem is that at this point, instance_vars is empty once more
got some example code of what you ultimately want to do?
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
just manually create the constructor
or use a macro to generate it if you really want
sure, but
def initialize(@nomad_base_url : URI) is pretty much the same and less confusing
this is a case of macro over complicating something that is simple
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