5 ms·

Until I can perform runtime define_method calls and dynamically construct classes, it doesn't matter what Crystal does. It's fundamentally antithetical to my ne

• yorwba 9y ago
  How late at runtime do these dynamic definitions need to be possible? Just at startup or also after the program has been running for a while? I occasionally wonder whether it might be possible to accommodate more dynamic language features with a compiler that treats them like a macro system that is expanded statically, such that no actual dynamicism is necessary at runtime.
  • sam0x17 9y ago
    This is exactly what crystal does
• sam0x17 9y ago
  You can do all of that with really easy to write crystal macros.
  • eropple 9y ago
    You can dynamically build at runtime an HTTP client from an OpenAPI spec (unavailable until runtime, to be clear), method-by-method, using macros? Tell me more.
    • sam0x17 9y ago
      Got me there. First time I've ever in my life heard of a legitimate example where you really do need dynamic methods.
      • eropple 9y ago
        If you're doing stuff with OpenAPI (as I've been doing over the last few weeks), it becomes a pressing thing. =( Generated clients usually are pretty awful, you usually have to generate your own (because they don't publish gems when their APIs change, which is why I've written online-generated ones!), and once you've completed the bootstrap process for an HTTP client, it's as fast as any other Ruby thing. Which is not the fastest out there by a long shot--though JRuby helps--but is Fast Enough for most stuff. I'm also not sure Crystal can implement an active record pattern off of a database? (Though I am not personally the type to go with that, I prefer row mappers.)
        • sam0x17 9y ago
          See GraniteORM or my crystal-mongo-orm. You just have to specify your fields at compile time and you are good-to-go. It works just like active record. https://github.com/amberframework/granite-orm https://github.com/amberframework/granite-orm https://github.com/sam0x17/crystal-mongo-orm https://github.com/sam0x17/crystal-mongo-orm
          • eropple 9y ago
            "You have to specify your fields at compile time" is exactly not like ActiveRecord, though. That's exactly the downside to it for doing ActiveRecord. At that point, you may (should) just use an object mapper like ROM that has no model-class hooks at all. (Which I actually like. But the Rails world disagrees.)
            • sam0x17 9y ago
              You effectively do specify your fields before runtime in Rails, though, in the form of your migrations. Furthermore all of the associations (belongs_to, etc), are arguably also specified before runtime since those helpers run when the class is parsed.
              • eropple 9y ago
    • papaf 9y ago
      Although it probably does not fit your use case something like Common Lisp would shine in a situation like this. You can build your code at runtime from the spec and then compile it at runtime to get pretty good performance.
      • eropple 9y ago
        Sure. Or I get effectively the same thing with JavaScript. (I just don't much like Node--it's not bad but it's not great--and the dev experience for specifying something like a DSL is a bummer.)
    • 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 ago
        The 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 ago
          For the sake of this example, consider [:thing, :other_thing] to be dynamically created at runtime.
      • eropple 9y ago
        You 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.
• sam0x17 9y ago
  People think "oh, it's compiled, so I can't have dynamic methods" but that couldn't be more far from the truth. You can do all of that at compile time, and Crystal provides an excellent way of doing so. E.g.: https://github.com/sam0x17/crystal-mongo-orm/blob/master/src/mongo_orm/fields.cr#L46 https://github.com/sam0x17/crystal-mongo-orm/blob/master/src...
• notalex 9y ago
  Reading well written source code creates a more efficient workflow than reading api docs. For me, the fact that Crystal is written in Crystal gives it a far greater advantage. Plus it is faster than Go/Java/Elixir. As others have pointed out, Crystal does have meta programming capabilities.