From: Alex Young <alex@...>
Date: 2006-05-06T18:20:54+09:00
Subject: Re: Sharp knives and glue

Ryan Leavengood wrote:
> Cool, this sounds like a plan David. This was exactly what I wanted my
> email to achieve. While we Ruby programmer's love the power and
> flexibility of re-opening classes, there are probably times when we
> all want to lock things down. Having the *option* of doing this
> shouldn't hurt anything, in my opinion.
> 
> FYI, I'm not sure if what you propose is possible in pure Ruby (at
> least easily), so if you can hack C you might have to look into making
> a C extension or a patch to the interpreter. Hopefully it won't be so
> bad though.

$ cat freeze-core.rb
@classes = {}
def do_freeze(klass)
   klass.freeze
   @classes[klass] = true
end
ObjectSpace.each_object do |o|
   do_freeze(o) if o.is_a?(Class) and !@classes.has_key?(o)
end

$ ruby -r freeze-core -e 'puts "foo"'
foo
$ ruby -r rubygems -r freeze-core -e 'puts "foo"'
foo
$ ruby -r freeze-core -e 'class String; def len; "foo"; end; end'
-e:1: can't modify frozen class (TypeError)

Something like that?

It also struck me that the require mechanism could be hijacked to 
enforce per-file namespacing to give something like Python's system, 
which seems to work fairly well.  A require_ns() that wraps a module 
named after the filename around the code it includes...  Would that help?

-- 
Alex

> 
> Regards,
> Ryan
> 
> On 5/5/06, David Pollak <pollak@gmail.com> wrote:
> 
>> Ryan,
>>
>> So... "Put your code where your mouth is?"... and given that my mouth is
>> big, my code should be good (my comments about me, and not ascribed to
>> you)... :-)
>>
>> I think you're absolutely right!
>>
>> I'll work on some 'lock-down' code that will allow classes to lock
>> themselves down from external modification (not Foo.freeze, but something
>> more granular.)
>>
>> I'll toss it out to the group and see what people have to say.
>>
>> Thanks,
>>
>> David
> 
>