On Tue, Jun 05, 2001 at 02:37:11PM -0500, Garrett Goebel wrote:
> > Before anyone gets the wrong idea, I don't think the solution is a
> > drastic scaling back in Perl's flexibility. I just don't know what
> > the solution is yet. Maybe it should be possible for a class to
> > completely seal off its namespace to the outside world on request.
>
> How do you determine "the outside world"? Out of the package's namespace or
> out of the file's?
It would have to be both. Nothing outside the namespace could peek at
or modify package data in that namespace, and no outside lexical
context would be allowed to use that namespace.
So if Foo.pm defines class Foo as being armored, Bar.pm couldn't do this:
package Bar;
{
package Foo;
print $Secret_Foo_Variable;
}
Of course, there's problems of order of definition. What happens if
Bar.pm is loaded before Foo? Dunno.
> When you say "seal off its namespace", do you mean that the symbol table
> would be thereafter static... or that only code within the predeclared scope
> could mess with the symbol table?
Only code inside that namespace could mess with stuff in that
namespace. It can all still change, but the changes cannot come from
outside its package.
> What about lexicals?
Lexicals already have their own privacy rules.
> How about:
>
> package_name.finalize();
> finalize package_name;
This is a different concept.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
I knew right away that my pants and your inner child could be best friends.
