Document Class.descendants advice

[alexanderadam]

A wise man, let's call him Ben, once said:

There are two reasons why this is an unreliable solution:

• it doesn't know about things that have yet to be autoloaded

• it's non-deterministic with regards to Garbage Collection of classes. If you use Class.descendants in Test, where there is a pattern to dynamically define classes, GC is unpredictable for when those classes are cleaned up and removed by the GC.

And I totally trust him on that because he's making a… GoodJob 🥁

There's also a PR to add a Cop to rubocop-rails (I'd assume that this will be sufficient or would you rather have that Cop implemented here as well?)

PS: I'm looking for a new adventure in case anybody is looking to hire or work with a Ruby/Rails/Crystal dev
PPS: would you be so kind and add the hacktoberfest-accepted label to this issue in case you find that PR helpful? 🥺

[Copilot]

Pull Request Overview

This PR adds guidance to the styleguide discouraging the use of Class#descendants due to reliability issues. The addition documents that Class#descendants is non-deterministic because it doesn't account for classes that haven't been autoloaded yet and can behave inconsistently with garbage collection, particularly in tests with dynamically defined classes.

• Documents the unreliability of Class#descendants with autoloading and garbage collection
• Provides a code example demonstrating the problematic pattern

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] The documentation should provide an alternative approach or workaround for scenarios where developers might need to track subclasses. Without suggesting alternatives, developers may be unclear on what to use instead of Class#descendants.