[ruby-core:109391] [Ruby master Feature#18930] Officially deprecate class variables

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


austin (Austin Ziegler) wrote in #note-12:
 
> > > but `Rand.dependents` producing `{1=>V1}` and `Timestamp.dependents` producing `{2=>V2,3=>V3,4=>V4}`.
> > 
> > I can easily imagine it as a _desired_ outcome (e.g., "every non-Vx class is root for its own list of versions, and stores them independently"). 
> 
> Possible, but IMO unlikely.

Well, it depends on the task. I have met several times with architecture like this:
```
AbstractBaseWidget - DashboardBaseWidget - {DashboardWidget1, DashboardWidget2, DashboardWidget3}
                  \
                    BillingBaseWidget - {BillingWidget1, BillingWidget2}
```
(with `AbstractBaseWidget` being "library base" without any necessity to know the system, but its immediate children are "roots" of sub-hierarchies and store their children.)

TBH, even by the first glance at your example, my first guess was "Vx's are stored in their own sub-hierarchies." So, "topmost class rules everything" is not a given—and maybe a good thing to pronounce explicitly.

Which leads us to...

> 
> I think that [...] the workarounds [with] `Base.dependents` are *less clear* in their intent and that the default behaviour is *unexpected*. Not wrong, but surprising.
> 

Would it be possible to expand on that, why it looks less clear for you? The question is not idle for me, I reflect a lot about Ruby's "intuitions", its documentation and "naturality" of the features; and I believe some insights might come out of trying to explain "how I read this" (instead of, how it frequently happens, end with "I see it clearer, period.")

From my side, choosing of three alternatives (tricks with copying variables on the fly aside):
1. `Base.descendants[name] = klass`
2. `descendants[name] = klass` (with `descendants` implemented however... say, with class variables!)
3. `@@descendants[name] = klass` (explicit use of class variables)

...for me, the reasoning on why prefer (1) to (2) goes like this:
* (2) reads (as it in all other places) as `self.descendants[name] = klass`
* with `self` being always _the current object_
* and what looks like "current object's attribute getter" probably encapsulates current object's data
* so in any of the intermediate descendants, the reader's _expectation_ would be "it has its own `descendants` copy"

So, it leaves us with `Base.descendants` vs `@@descendants`... With the latter being a "special sigil for helping in this exact case, and no else," and the former somehow perceived as "ceremony" and "boilerplate"?..

----------------------------------------
Feature #18930: Officially deprecate class variables
https://bugs.ruby-lang.org/issues/18930#change-98540

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
Ruby's class variables are very confusing, and it seem many people agree they should be avoided (#18927).

How about we deprecate them officially?

Concretely:
* Mention in the documentation that class variables are deprecated and should be avoided/should not be used.
* Add a parse-time deprecation warning, now that we only see those with `Warning[:deprecation] = true` it seems reasonable to add.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>