Feature #8365

Make variables objects

Added by Anonymous over 3 years ago. Updated 5 months ago.

Target version:


While refactoring a wiki article about Ruby, I found this anonymous proposal:

"How about making variables objects. And assignment is the default message you send to the variable object (not the underlying reference). anintvar 5, now the variable "anintvar" is a reference to the constant integer 5. And since variables are objects, you can do some neat things like subclass variables. It would be a mixed world of static variable typing and dynamic. Use the appropriate one for a given scenario. You could also do linear casting. exm.
integer new anintvar 5
char new acharvar anintvar

Variable types and the reference object they point to can be 2 different types. But the variable decides how to do the casting not the object referenced. "anintvar" and "acharvar" reference the same object."

I am pasting this anonymous proposal here in original full length, before I rewrite it to a more concise form in that wiki page.


#1 [ruby-core:54771] Updated by Yukihiro Matsumoto over 3 years ago

  • Status changed from Open to Feedback
  • Assignee set to Yukihiro Matsumoto

I am sorry I don't understand the proposal, nothing more than vague idea.
Proposals should be concrete and be able to implement.

Could you describe both the model and the syntax for the proposal?


#2 [ruby-core:54796] Updated by Anonymous over 3 years ago

Here is my understanding of the original author's idea, which, I hope, will not turn out to be dismally and irremediably flawed. Its mind-boggling quality pleasantly intrigues me, as is the case with many extant Ruby features. I was made receptive to the original author's idea, as I just recently implemented emancipated constant magic (#7149). I don't see such a big difference between constant assignment hooks and variable assignment hooks – Ruby constants, I understood, are just squeamish variables after all.

Firstly, the syntax part of the original proposal ("integer new anintvar 5" and such) is, imho, crap. But the idea of Variable class titillates me. With variables, I see two separate issues:

  1. Variable contents (what is assigned to it)
  2. Membership in (speaking in my own terminology) a "club" of variables.

Concentrating on 2: Each variable is created a member of some club. For a constant, this club is the namespace, to which the constant belongs. For an instance variable, an instance. For a class variable, a class. For a global constant ... hm ... a club of global constants. For a local variable ... hm ... hm ... a binding? (I really don't know much about how local variables are organized.)

The hierarchy of variable classes, as I feel it, would be:

  • class Variable
    • class Constant < Variable
    • class InstanceVariable < Variable
    • class LocalVariable < Variabls
    • class GlobalConstant would be either < Variable, or < Constant
    • class ClassVariable would be probably < Variable, less likely < InstanceVariable

So this class hierarchy part is a bit vague. I'm not really sure about it. But when I write

foo = 42

this is what would happen behind the scenes: :foo, club_of_local_variables ).set( 42 )

42 would thus be assigned to LocalVariable instance :foo, which would be reachable from the regional club of local variables (binding?). One would be able to create variable subclasses:

# This is a "typed" variable that compulsorily applies Array() to its value
class LocalArrayVariable < LocalVariable
  def set value
    super( Array( value ) )

And hooks, that would cause stuff to happen when specially named variables are assigned to:

class << LocalVariable
  alias old_new new
  def new( symbol, club )
    if symbol.to_s.starts_with? "array_" then symbol.to_s[6..-1].to_sym, club ) # strips away "array_"
      old_new( symbol, club )

Maybe this "alias old_new new" is not the best possible hook practice, but nevertheless:

array_foo = 42

would cause "foo" to be assigned value [42]

foo #=> [42]

With this, esoteric behavior of sigils ($, @) could be made exoteric, if not, heaven forbid, user modifiable. One could make variables first

module Foo; end
variable = :Bar, Foo

and actually assign them later

variable.set( "Bar" )
Foo::Bar #=> "Bar"

The variable object could tell us its attributes #=> :Bar #=> :Foo
# Of course, :club keyword is a joke, I don't know any better name

hand us its value

variable.get #=> "Bar"


variable = "Bar"

would simply assign "Bar" string to "variable" variable. Who knows, perhaps what is today known as Binding, could just become a collection of Variable instances?

One also wonders, what would the relationships between variables and their clubs be. Could they abandon their club (and be garbage collected as unreachable)? Could the variables transfer to other clubs? Or could clubs fire them for bad performace? Could they change name? There is potentialy a host of problems, which I as a C-illiterate user, do not fully realize...

#3 [ruby-core:54801] Updated by Yukihiro Matsumoto over 3 years ago

Interesting, but this would make Ruby VERY SLOW.
I am not sure whether it's worth the performance degration.


#4 [ruby-core:65121] Updated by Anonymous over 2 years ago

I have noticed newly added Binding#local_variable_get and Binding#local_variable_set. I wanted to express appreciation.

#5 [ruby-core:76985] Updated by Boris Stitnicky 5 months ago

I deleted my account by mistake so my earlier posts show as 'Anonymous'. I'm back and curious how this feature request resolves in the end.

Also available in: Atom PDF