4 ms·
Yeah use Ruby. I prefer to have well defined interfaces for the objects I use. I love Ruby to death, but it's frustrating to encounter code like this: [:thin
by look_lookatme 9y ago
Yeah use Ruby. I prefer to have well defined interfaces for the objects I use. I love Ruby to death, but it's frustrating to encounter code like this:
[:thing, :other_thing].each do |msg|
define_method(msg) do
@json[msg].to_s
end
end
When this is far more clear and, for me, aesthetically pleasing:
def thing
@json[:thing].to_s
end
def other_thing
@json[:other_thing].to_s
end
I'm not sure how you'd use a ruby object that maps to an OpenAPI spec if you don't know what's in the API response until runtime... surely you or the user of your library has an idea what's in the API they are consuming?
- yxhuvud 9y agoThe example in question is perfectly possible to do in Crystal during compile-time, using macros. What isn't possible is to create a new class on the fly as a sort of magic lookup table that magic methods is called upon. Good riddance, for that functionality.
- look_lookatme 9y agoFor the sake of this example, consider [:thing, :other_thing] to be dynamically created at runtime.
- eropple 9y agoYou may have an idea, sure, but the alternative is to codegen a new instance of the client library any time anything changes rather than keeping up to date with the API as it evolves and exists. (The moral equivalent is pulling a WSDL during app startup and making sure that you're presenting a correct interface to it.) I full-stop don't do codegen in any project under any circumstance that is not done strictly within the workflow of a build tool (i.e., a Maven generated-sources gizmo). OpenAPI's options are pretty much all exactly not that: all the codegen options's happy paths seem to be vendoring generated code. And that makes me itch, too.