[#109115] [Ruby master Misc#18891] Expand tabs in C code — "k0kubun (Takashi Kokubun)" <noreply@...>

Issue #18891 has been reported by k0kubun (Takashi Kokubun).

13 messages 2022/07/02

[#109118] [Ruby master Bug#18893] Don't redefine memcpy(3) — "alx (Alejandro Colomar)" <noreply@...>

Issue #18893 has been reported by alx (Alejandro Colomar).

11 messages 2022/07/02

[#109152] [Ruby master Bug#18899] Inconsistent argument handling in IO#set_encoding — "javanthropus (Jeremy Bopp)" <noreply@...>

Issue #18899 has been reported by javanthropus (Jeremy Bopp).

10 messages 2022/07/06

[#109193] [Ruby master Bug#18909] ARGF.readlines reads more than current file — "JohanJosefsson (Johan Josefsson)" <noreply@...>

Issue #18909 has been reported by JohanJosefsson (Johan Josefsson).

17 messages 2022/07/13

[#109196] [Ruby master Bug#18911] Process._fork hook point is not called when Process.daemon is used — "ivoanjo (Ivo Anjo)" <noreply@...>

Issue #18911 has been reported by ivoanjo (Ivo Anjo).

9 messages 2022/07/13

[#109201] [Ruby master Bug#18912] Build failure with macOS 13 (Ventura) Beta — "hsbt (Hiroshi SHIBATA)" <noreply@...>

Issue #18912 has been reported by hsbt (Hiroshi SHIBATA).

20 messages 2022/07/14

[#109206] [Ruby master Bug#18914] Segmentation fault during Ruby test suite execution — "jprokop (Jarek Prokop)" <noreply@...>

Issue #18914 has been reported by jprokop (Jarek Prokop).

8 messages 2022/07/14

[#109207] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedYet — Quintasan <noreply@...>

Issue #18915 has been reported by Quintasan (Michał Zając).

18 messages 2022/07/14

[#109260] [Ruby master Feature#18930] Officially deprecate class variables — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18930 has been reported by Eregon (Benoit Daloze).

21 messages 2022/07/20

[#109314] [Ruby master Bug#18938] Backport cf7d07570f50ef9c16007019afcff11ba6500d70 — "byroot (Jean Boussier)" <noreply@...>

Issue #18938 has been reported by byroot (Jean Boussier).

8 messages 2022/07/25

[#109371] [Ruby master Feature#18949] Deprecate and remove replicate and dummy encodings — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18949 has been reported by Eregon (Benoit Daloze).

35 messages 2022/07/29

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

From: "austin (Austin Ziegler)" <noreply@...>
Date: 2022-07-31 00:24:27 UTC
List: ruby-core #109390
Issue #18930 has been updated by austin (Austin Ziegler).


jeremyevans0 (Jeremy Evans) wrote in #note-10:
> austin (Austin Ziegler) wrote in #note-9:
> > If we’re going to deprecate them, we need something that effectively replaces them—and class instance variables aren’t it.
> The particular approach given may not work (I don't see how it tries to replace class variables), but that doesn't mean you cannot replace class variables with class instance variables.  There are a couple approaches, depending on the behavior you want.

It doesn’t—as such. This was something I coded up and was *surprised* that it didn’t work the way that I expected, and exploring it resulted in the understanding that I have. The *intent* that I had was very much one where I got the behaviour from a class variable instead of a class instance variable. Both suggestions you made would absolutely work, although if this were something that I exploring further, I’d be doing much more work on it (probably building out a bit of a DSL; for what I’m writing, it’s overkill).

zverok (Victor Shepelev) wrote in #note-11:
> > 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.

Note that I’m in favour of officially deprecating class variables, but this is *one* scenario where the use of a class variable instead of a class instance variable provides a desirable effect with minimal code compared to replicating the behaviour with class instance variables. I think that all three of the workarounds (`Base.dependents` or either of Jeremy’s) are *less clear* in their intent and that the default behaviour is *unexpected*. Not wrong, but surprising.

One of the reasons I still like writing Ruby is there’s very little *ceremony* / boilerplate. For this advanced use, it would be nice to have that remain the case.

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

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

In This Thread