From: "Chr. Rippel" <chr_news@...>
Date: 2002-01-16T04:33:48+09:00
Subject: Re: A possible class variable bug? - Re: a wishlist for ruby 2.0

"Paul Brannan" <paul@atdesk.com> wrote in
....
> On Tue, Jan 15, 2002 at 12:30:27PM +0900, Chr. Rippel wrote:
> > Well following this logic it might make sense to (re)unfiy the concepts
> > of class variables and global variables the ladder being class variables
> > of the class Object.  A somewhat radical version would be the removal of
> > class variables all together since it's possible to simulate the effect of
> > class variables using only class instance variables and class accessory
> > methods (since this has a "pythonish" touch to it surely won't fly;-)
> > In cvs you get ...
>
> I don't think this is safe.
>
> 1) It opens up access to the class's instance variables to the entire
> world; class variables are available only to the class and its
> descendants.

Hm, that is actually a very good point (besides the fact that you can easily
break the type of ``security'' provided of being an instance variable)
which brings me to something high on my personal wish list for Rby 2.0 -

  * instance_protected class/module_methods

- that is if a singleton_method klass#foo of the Class(Module) object
klass is marked ``instance_protected'', klass#foo can only be invoked
 inside  a method of an instances of klass or its decedents (respectively
``includies'').

> 2) What happens when I define an accessor to instance variables in both
> the derived class and the base class?  If Bar is a subclass of Foo, and

Well you have the exact same problems with class_variables - additional
method creation in descant classes would never happen since you would
obviously automate this (with a possibly finer control of visibility) - as
for retroactively adding these methods to parent classes there nothing
you can do about this but this true for class_variables as well.


> foo is the accessor to class variable, then I have the option of calling
> (from an instance method):

>   Foo.foo
>   Bar.foo
>   self.type.foo
>
> Generally, a class should not have to know its name, but if I call
> self.type.foo, then I get a different class variable depending on
> whether I instantiated a Foo or a Bar.

Okay this would not for work with anonymous classes however playing on the
scheme we might do something like

------
class A
  NameSpace =self
  class << self
    protected
    attr_accessor :__klass_var
    def klass_var
      NameSpace.__klass_var
    end
    def klass_var=(rval)
       NameSpace.__klass_var=(rval)
    end
  end
  protected
  def klass_var
    NameSpace.send :__klass_var
  end
  def klass_var=(rval)
    NameSpace.send :__klass_var=, rval
  end

  # the following is a parsing issue - i.e. we have to explain to
  # ruby that we want to invoke self.klass_var=("A")

  send :klass_var=, "A"

end

class B < A
  send :klass_var=, "B"
end

def A.var
  puts klass_var
end

A.var  # => B
B.var  # => B
------

Anyway I am not seriously suggesting removing class variables since
their use is by now too entreched -  but I am sort wandering if they
don't become a liability when the mythical Namespaces technolgy
is introduced.


/Christoph


Ps. High on my personal list for Ruby 2.0 would be the

*  unification of Symbols and Strings as arguments for ``method creating''
   methods (see RCR # 56,57 or 58 I believe)

which I believe should be possible by sub classing Symbol from String
(you have to remove all self modifying String methods etc.)