• Davide (unregistered)

    This reminds me of my old software lead. After he left I spent a lot of time searching for a specific class property which apparently was never defined... until I discovered that he was using C macros to automatically generate classes with dynamical names, all of them with a single property mClassName, that of course no IDE was able to find as the "m" was added by the macro. In the end he was using this brillant technique for a number of objects that was limited by the current process we were dealing with, so he developed a 3-line preprocessor macro to save 3 lines of code. I was so happy when he left.

    (also: Frist?)

  • Tim (unregistered)

    If you think this is bad, you have obviously never used asp.net MVC or core. Thanks to the philosophy of "convention over configuration", every time the built in mega god object receives a request, it goes through a huge mire of reflection calls to figure out which classes and methods might be able to handle it, then picks one if there are several. There are of course many ways to customise the routing just to make it more "convenient"

  • (nodebb)

    Many years of Ruby have taught me that constantize can/should only be used in very specific circumstances - generally if you're writing a framework and are using something like YAML settings where you can't reference objects directly. The only other genuine use case I've found is if you have a huge pile of per-customer parsers or the like. But dynamically defining and/or referencing methods and classes needs to be used really judiciously if at all. Unfortunately Ruby makes it just way too easy to do it. :(

  • Hal (unregistered)

    Honestly this seems more like a documentation problem than anything else. Ruby lends itself to a lot of cleverness. The best thing about it very often you can get a lot of functionality out of very few lines of code and as long as you understand the thinking that went into it, it is very quick to read and understand. Ruby full on encourages meta-programing and DSL (domain specific language) creation.

    Its all fine, but as others have pointed out IDEs struggle and it really defies SAST tools being able to understand it. When it comes to big projects through you need a 'theory of operation' written down somewhere by whoever created otherwise it absolutely can be a mess of incantations calling methods and classes that don't seem to be defined anywhere, and all kinds of magic behavior thru clever scope tricks.

    Ruby isnt a language its an environment. There are collection of idioms and patterns the community embraces you should use, then for big projects you add your own. What needs to be remembered and frankly many Rubists forget is that idioms don't translate. "Like Goose-sh** thru a tin horn" only means something to you if you are from the right corner of North Carolina, the rest of us need an explained if you are going to toss that term around. That needs to be in the docs some place.

  • Officer Johnny Holzkopf (unregistered)

    This approach might be one of the forgotten ancestors of today's AI: a way to have a program write a program depending on suggestions coming from a config file as text. If this could evolve, one day it might start to ConstantlyCamelCaramelDansen...

  • (nodebb) in reply to Officer Johnny Holzkopf

    Dibs on Camel Caramel as a band name!

Leave a comment on “A Ruby Encrusted Footgun”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article