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 [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 = 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"
Whereas
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...
Updated by matz (Yukihiro Matsumoto) about 12 years ago
Updated by