Re: Scoping and locating definitions

On Sat, Jan 20, 2007 at 02:18:19AM +0900, Jos Backus wrote:
> On Fri, Jan 19, 2007 at 06:40:03PM +0900, Pit Capitain wrote:
> > Jos Backus schrieb:
> > >(...)
> > >What if I wanted String#rot13 to _not_ be visible in file `r' (because I
> > >didn't ask for it)?  How do I contain the change to String to lib.rb only? 
> > >Or
> > >perhaps to Foo?
> > 
> > Jos, using this library
> > 
> >   http://raa.ruby-lang.org/project/import_module
> > 
> > you can get the desired behaviour. The library hasn't been updated for 
> > some time, but it still seems to work with Ruby 1.8.5. I got some 
> > warnings, but it is easy to change the code to get rid of them.
>  
> Thanks Pit, I'll have a look and will report back.

After looking at this I'm not sure how this helps me. Can you give an example
please?

I guess I wasn't describing the problem fully. As I see it, there are two
issues: restricting imports (which import_module alledgedly addresses) and
restricting exports. The earlier example causes String to be extended with
.rot13 for everybody who includes `lib.rb'. I'd like there to be some way that
String#rot13 would not be available outside `lib.rb' unless asked for.  IOW,
in addition to being able to control what is being imported it would be good
to be able to control what is being exported.

As an example, consider the following syntax. Its effect would be that String
is only extended inside class Foo; references to String#rot13 outside of class
Foo should fail. This would allow one to locally extend String without
polluting String everywhere as is the case today.

    class Foo
      with class String
	def rot13
	  tr 'A-Za-z', 'N-ZA-Mn-za-m'
	end
      end
      def initialize(s)
	@s = s
      end

      def bar
	@s.rot13
      end
    end

As an aside, a while ago I ran into the fact that Process is a built-in class
whereas I wanted my own class to be named Process instead, given that I wasn't
going to use the built-in Process class anyway.
Perhaps it would be better if Ruby made less classes available without
require'ing them (maybe limited to a set of primitives). So to get what one
has today one would say

    require 'core'

or something like it. core in turn could be subdivided into useful subgroups.

-- 
Jos Backus
jos at catnook.com