Feature #9565: Unifying the methods (const|class_variable|instance_variable)_(defined?|get|set)

• Status: Rejected
• Assignee: -
• Target version: -

[sawa (Tsuyoshi Sawada)]

An argument to methods of the form (const|class_variable|instance_variable)_(defined?|get|set) already describes if it is meant to be a constant, class variable, or instance variable. For example, if "Foo" were to be used as an argument, a meaningful usage may be using it with const_get, but not class_variable_get or instance_variable_get. Whenever I use these methods, I feel redundancy and extra burden of having to repeat the information twice (once by method name and once by capitalization/sigil).

I propose that if we use a common word (let's say token, but I am not sure of this naming) in place of the words const, class_variable, and instance_variable, and have methods to unify them and get rid of the redundancy, then it would be easier for programmers. Particularly, Object should have the following instance methods that are aliases of the conventional methods:

token_defined? ==> instance_variable_defined?
token_get      ==> instance_variable_get
token_set      ==> instance_variable_set

and Module should have the following instance methods that call different methods or error depending on the first argument:

token_defined? ==> const_defined?              (for capitalized arguments like "Foo")
               ==> class_variable_defined?     (for arguments prepended with @@)
               ==> instance_variable_defined?  (for arguments prepended with @)
               ==> Error                       (otherwise)

token_get      ==> const_get                   (for capitalized arguments like "Foo")
               ==> class_variable_get          (for arguments prepended with @@)
               ==> instance_variable_get       (for arguments prepended with @)
               ==> Error                       (otherwise)

token_set      ==> const_set                   (for capitalized arguments like "Foo")
               ==> class_variable_set          (for arguments prepended with @@)
               ==> instance_variable_set       (for arguments prepended with @)
               ==> Error                       (otherwise)

So when we use this, we do not have to think about the complicated method name; we just need to provide the right argument:

module A
  token_defined?("Foo") # => false
  token_set("Foo", 1)
  token_get("Foo")      # => 1

  token_defined?("@@foo") # => false
  token_set("@@foo", 2)
  token_get("@@foo")      # => 2

  token_defined?("@foo") # => false
  token_set("@foo", 3)
  token_get("@foo")      # => 3
end

[sawa (Tsuyoshi Sawada)]

And I forgot to mention local_variable_(defined?|get|set) on Binding. I propose that Binding should have these methods:

token_defined? ==> instance_variable_defined?  (for arguments prepended with @)
               ==> local_variable_defined?     (for lowcase arguments like "foo")
               ==> Error                       (otherwise)

token_get      ==> instance_variable_get       (for arguments prepended with @)
               ==> local_variable_get          (for lowcase arguments like "foo")
               ==> Error                       (otherwise)

token_set      ==> instance_variable_set       (for arguments prepended with @)
               ==> local_variable_set          (for lowcase arguments like "foo")
               ==> Error                       (otherwise)

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

I don't see the benefit of unifying. You said 'easier' but I don't see how unifying makes programming easier.
Unless you describe the benefit more concretely, I have to reject.
Feel free to reopen, if you come up with the reason.

Matz.

[trans (Thomas Sawyer)]

+1 Fewer methods to remember. Could be used for global vars too. Is token the best term though?