From: "zverok (Victor Shepelev)" Date: 2022-07-31T11:42:50+00:00 Subject: [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: