Make variables objects
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 matz (Yukihiro Matsumoto) about 5 years ago
- Status changed from Open to Feedback
- Assignee set to matz (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 about 5 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:
- Variable contents (what is assigned to it)
- 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:
LocalVariable.new( :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 ) ) end end
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 LocalArrayVariable.new( symbol.to_s[6..-1].to_sym, club ) # strips away "array_" else old_new( symbol, club ) end end end
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 
foo #=> 
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 = Constant.new :Bar, Foo
and actually assign them later
variable.set( "Bar" ) Foo::Bar #=> "Bar"
The variable object could tell us its attributes
variable.name #=> :Bar variable.club #=> :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...