Issue #18273 has been updated by zverok (Victor Shepelev). TBH, I still fail to see the point of how the API clearly reflecting the reality should be considered a "broken window". Two subsequent calls returning different results without user's code affecting these results is not that uncommon: if you'll try to introspect the current state/list of threads, or fibers, or ractors; if you try to look at files and directories while something else changed them; well, if you just `Time.now` two times in a row... From my perspective (being obsessed with docs and teaching people) it is rather fortunate that with `Class#subclasses` we'll have a clear and obvious place to write: yes, subclasses may vanish, please beware and remember; it is an important thing to say explicitly! I don't think "that would be strange" is a strong enough argument here, if it clearly reflects *what's really going on*. ---------------------------------------- Feature #18273: Class#subclasses https://bugs.ruby-lang.org/issues/18273#change-96120 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal ---------------------------------------- Ref: https://github.com/rails/rails/pull/43481 Something we forgot to mention in [Feature #14394], is either a parameter or another method to only get direct descendants. Active Support has been offering `Class.subclasses` as: ```ruby def subclasses descendants.select { |descendant| descendant.superclass == self } end ``` It seems a bit silly to grab all descendants and then restrict the list when `Class#descendants` had to do some recursion to get them all in the first place. ### Proposal We could either implement `Class#subclasses` directly, or accept a parameter in `Class#descendants`, e.g. `descendants(immediate = false)`. cc @eregon -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>