[ruby-core:107256] [Ruby master Feature#18273] Class#subclasses

Issue #18273 has been updated by zverok (Victor Shepelev).


@fxn Isn't it an inherent property of a dynamic language, that whatever you can introspect about the code structure, can change in runtime? So the methods truthfully reflecting the current state of the structure are perfectly sane? 

I'd argue it is not a qualitative difference from a change of the `subclasses` because something was _defined_ in runtime. I can see how it can be said to be different (because in the case of subclass vanishing, nothing on user level of the program can be pointed as a code that led to the change), but is this difference practicalor only affects "theoretical clarity"?

I assume that as a developer of the Zeitwerk you maybe can provide some insight on practical consequences?

----------------------------------------
Feature #18273: Class#subclasses
https://bugs.ruby-lang.org/issues/18273#change-96117

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>