At 07:29 PM 6/5/01 +0100, Michael G Schwern wrote:
>Consider the following... Foo is a poster-child for a strict class.
>Everything is predeclared and typed. Its entire hierarchy is rock
>solid. Someone uses Foo in their script and calls Foo->bar. They
>also use Bar, a module you installed a long time ago. Bar does this:
>
> package Bar;
> eval "sub Foo::bar { 23 }";
>
>Oh crap! All the wonderful compile-time checking we did on Foo has
>just been blown to pieces.
>[snip]
>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.
I would like to see some sort of "use really_strict" pragma which would
disable at compile time the kinds of things you mentioned:
>No subroutine refs. No dynamic inheritance. No autoloading. No
>dynamic method calls. No symbol table manipulation. No eval. No
>automatic method generation. (That's off the top of my head).
Of those, only subroutine refs and automatic method generation look like
must-haves for major projects, which are willing to surrender some of the
cute stuff in return for stability.
Quite how Foo prevents Bar from causing shenanigans if Bar was used first,
I don't know; might not be possible until runtime.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
