From: "boris_stitnicky (Boris Stitnicky)" <boris@...>
Date: 2013-05-05T15:26:43+09:00
Subject: [ruby-core:54796] [ruby-trunk - Feature #8365] Make variables objects


Issue #8365 has been updated by boris_stitnicky (Boris Stitnicky).


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 (http://bugs.ruby-lang.org/issues/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) an "organization of variables".

Concentrating on 2: Each variable is created a member of some organization. For a constant, this organization 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 ... an organization 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, appropriate_organization_of_variables ).=( 42 )

One would be able to create variable subclasses:

    # This is a "typed" variable that compulsorily applies Array() to its value
    class LocalArrayVariable < LocalVariable
      def = 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, organization
        if symbol.to_s.starts_with? "array_" then
          LocalArrayVariable.new symbol.to_s[6..-1].to_sym, organization # strips away "array_"
        else
          old_new symbol, organization
        end
      end
    end

Maybe this "alias old_new new" is not the best possible technique, but it still:

    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, lord forbid, user modifiable. Moreover, one could create variables first

    module Foo; end
    variable = Constant.new :Bar, Foo

and perform the actual assignment separately

    variable.=( "Bar" )
    Foo::Bar #=> "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?
----------------------------------------
Feature #8365: Make variables objects
https://bugs.ruby-lang.org/issues/8365#change-39137

Author: boris_stitnicky (Boris Stitnicky)
Status: Feedback
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: 
Target version: Next Major


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.


-- 
http://bugs.ruby-lang.org/