> $ 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?

Here are my ideas (bearing in mind that I am not much of a Ruby programmer):

I don't want any of my classes frozen. Say I want all string objects
passed to my function to be able to represent themselves in a certain
way...
ie. my function needs strings in culy braces. So the natural thing for
me would be this:

class String
  def curlify
    "{"+self+"}"
  end
end

This is where I need the curlies and it makes sense for them to be there.

I even want to be able to say:
require "curlystrings"

And have my strings be able to be curly.

What might be better, though is something like this:

irb> require "curlystrings"
unsafe require, "curlystrings.rb" attempts to add new definition
"curlyify" to existing class "String" in line 5 of
"/home/lesliev/curlystrings.rb". You may want to use
require_over_existing.

irb>
irb> require_over_existing "curlystrings"
=> true

That's the one thing - if I require something, it can't modify
pre-existing classes without me authorizing that.

The other thing is that a gem or library should not be loaded unless I
"require" it. This was the Glue problem. So unless I say "require",
what is not listed in the "built in classes and modules" part of the
Ruby manual should not be part of my environment.

Is this all reasonable?