Hacker News new | ask | show | jobs
by inopinatus 1292 days ago
Perhaps even more egregiously: given Ruby's dynamic runtime, we may take an apparently immutable instance of a data class and variously prepend, extend, refine or define methods upon that object's class or eigenclass such that, one way or another, different values are returned, for subsequent uses of that object, with your choice of lexical or global scope, including effecting mutability to the extent of providing viable setter methods.

Actually doing so breaks the covenant of Data, but an enforced prohibition breaks the language. As with Struct before it, a data class is merely a shorthand.
1 comments
prescriptivist 1291 days ago
> Actually doing so breaks the covenant of Data, but an enforced prohibition breaks the language.

Fortunately in my almost 20 years of ruby, dark magic does not survive a reasonable amount of sunlight. Most of the time someone (including me) has written impolite ruby, they know what they are doing and why (laziness 90% of the time) and respond appropriately to a gentle prod to be more polite.

link
JohnBooty 1291 days ago
This has been my experience as well.

Ruby gives you footguns and you can certainly do ill-advised things... but in practice I just don't see it happening very often either in open source projects or in private corporate stuff.

Why?

Because IME there's rarely even a need to go down those paths at all, unless you are writing a framework or doing something else "meta."

99.99% of Ruby I have actually seen is either simple scripts or bog standard OO stuff.

link
inopinatus 1290 days ago
> a framework

We do find such horrors lurking in the bowels of Rails, unsurprisingly. ActiveSupport clamps on to several fundamental modules, but Rails only inflicts the worst of its metaprogramming gymnastics either upon itself, or client objects/classes that expect a ton of magic (viz. models, controllers, views). When peeking at some of the machinery I'm sometimes unsure whether to be appalled or astounded.

link
prescriptivist 1291 days ago
Agreed. And if you have a rigid tests-are-necessary-to-merge regime you end up finding that the simplest way to write quality tests are simple approaches to implementations.
link