Re: RFC 254 (v1) Class Collections: Provide the ability tooverload classes

> >So anyhow, yes, this is a big, icky problem.

We want to subclass things but have them still retain their old pre-modification
names, w/o changing the thing we are altering (only masking it.)

Right?

Here's an alternate approach:

What if, instead of adding an additional and confusing bag of tricks
pertaining to interrelation of related classes, we were able to set
up separate, discrete visibility regions -- sort of like the unix C<chroot>
command -- where packages could not interfere with each other.  We would
be able to load the class to be modified (the "victim") into a space where
it will not know it is in a space --  and then we could alias all the method calls
to the victim, where they are supposed to go, to the victim, where it really is.

We would need a pragma to chroot our context to be under the current package,
a primitive to create a defaultish environment within the virtual space,
and a macro that exports all the functionality of a virtual package into the
current package.

Setting up the japanese forest, the example from 254.1, might then work like this:

   {
     chpackroot Frog;	# this is a severely new keyword and subject to change
     use Frog;		# has no idea it is defining Frog::Frog

   };	# close chpackrooted environment

   package Frog;

   sub speak { print "kerokero"; }

   foreach (?????) {	# go through all the methods defined in Frog::Frog
			# I know there is a way to do this but do not know what it is
      #next if $_ eq speak;  
      next if defined \&$_; 
      eval "sub $_ { return &Frog::Frog::$_ @_ }";
   };

First we create a virtual environment to load the package into, then we
define the methods we wish to overload, then we define all the methods
to pass through the args -- No, this is not needed at all, we can use ISA
for that can't we!
 
   package Frog;

   @ISA = qw('VIRTUALZONE::Frog');
   sub speak { print "kerokero"; }

which means that all that is required is a package root changer.
I wonder how hard that would be to implement.


-- 
                          David Nicol 816.235.1187 [email protected]