[#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
[ruby-core:109396] [Ruby master Feature#18930] Officially deprecate class variables
From:
"austin (Austin Ziegler)" <noreply@...>
Date:
2022-07-31 17:06:43 UTC
List:
ruby-core #109396
Issue #18930 has been updated by austin (Austin Ziegler).
Eregon (Benoit Daloze) wrote in #note-15:
> Regarding @austin's example, there is Class#subclasses now which might be an easier way to do that.
Not really, because that would require some sort of runtime filter of said subclasses. The concept I was putting together is that there are some defined *ways* of doing things that are versioned. V1 uses a random generator; V2, V3, and V4 use a timestamp generator. There’s a payload that would include an integer version number and then it would be something like `Verifier[version].verify(payload)`, where `Verifier.[]` returns the class, but *only* if it’s versioned. Using `Class#subclasses` would mean that `Verifier.[]` would need to filter based on `Class#name` matching `V#{version}`. This would be runtime looping that doesn’t work with the intended performance characteristics.
> > deprecating them is just removing a tool from the programmer's toolbox
>
> Yes, in this case I think this is good because it's a tool which is very difficult to use correctly and can easily be replaced by clearer ways like instance variables, constants, etc.
I agree that `@@vars` are *very* hard to use properly and are best deprecated with a long-term plan of removal…but I’m not as convinced that the alternative ways are *clearer*. I’ve been using Ruby for 20 years now and *still* was a little surprised when I tried what I tried and ended up with separate hierarchies. I think that, in order to deprecate them, good documentation needs to be written on how and when to use the alternatives *instead* of class variables. (This brings up a different issue, in that "how the language works" documentation is sparse and poorly organized; where is the discussion of instance variables, class instance variables, and class variables to be found in https://docs.ruby-lang.org/en/3.1/index.html?)
----------------------------------------
Feature #18930: Officially deprecate class variables
https://bugs.ruby-lang.org/issues/18930#change-98547
* 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:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>