From: Austin Ziegler <halostatue@...>
Date: 2004-12-06T13:32:54+09:00
Subject: Re: Freezing Variable Assignment

On Mon, 6 Dec 2004 11:51:55 +0900, Nicholas Van Weerdenburg
<vanweerd@gmail.com> wrote:
> Is there a feature to freeze variable assignment?
> 
> e.g.
> a="hello"
> a.assignfreeze
> a="goodbye"  # ===> generates exception

No, but you might be able to do something with WeakRef (weakref.rb)
or some other proxy class and freezing that.

  class Var
    def initialize(value)
      @value = value
      @const = false
    end

    def const!
      @const = true
    end

    def const?
      @const
    end

    attr_accessor :value
    def value=(value)
      raise "Var #{@value.inspect} is constant." if const?
      @value = value
    end

    def class
      @value.class
    end

    def id
      @value.__id__
    end

    def method_missing(sym, *args)
      @value.send(sym, *args)
    end

    def inspect
      @value.inspect
    end
  end

  a = Var.new("hello")
  a.value = "goodbye"
  a.class
  a.const!
  a.value = "yo!"

> Or, in a related vein, a type freeze, so that only similar objects
> can be added.

Define "similar objects". What if I want a variable to be only an
IO? Should I restrict it to items which inherit from IO? If so, I
lose the ability to transparently use StringIO or ZLib::GzipWriter
(or GzipReader) objects. This gets to the heart of why static typing
is generally a bad idea -- it makes classes less extensible, and
when you have static typing enforced by the language, there's almost
always ways to escape out of it with no protection from the compiler
involved (e.g., pointers).

> I realize that constants offer assignment freezing to a certain
> degree.
> 
> The reason I ask, is that I stepped over-top of some framework
> variables today, and it was hard to find out what was going on.
> Where as ruby protects keywords, it would be nice if frameworks or
> custom domain specific languages could do the same.

What do you mean, specifically? Did you reopen the classes in the
framework, or something? If the framework put variables in such a
way as to make it easy for you to overwrite something that shouldn't
have been, then I think that it's a bug in the framework, not in
your code. In some ways, Transaction::Simple is a framework, and I
have deliberately made it "hard" to step on Transaction::Simple
variables.

On Mon, 6 Dec 2004 12:22:35 +0900, itsme213 <itsme213@hotmail.com>
wrote:
> "Nicholas Van Weerdenburg" <vanweerd@gmail.com> wrote in message
>> Is there a feature to freeze variable assignment?
>> 
>> e.g.
>> a="hello"
>> a.assignfreeze
>> a="goodbye"  # ===> generates exception
> I like this, specially if it also covers instance variables. I
> think Ruby's current freeze is a special case, in which all
> instance variables of the given object are frozen.

Um. Not really. Only the direct replacement of those objects is
frozen.

  a = Struct.new("Effable", :a, :b).new
  a.a = "abcdef"
  a.b = %w(a b c d e f)
  a.freeze
  a.a = "ghijkl"        # raises error
  a.a.gsub!(/a/, 'z')   # no error
  a.b[0] = 'z'          # no error

Freeze isn't necessarily recursive.

> It's in the same vein that I think Observable should target a
> instance variable (an attribute, more generally) of an object,
> rather than an entire object.

Why?

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca