On Tue, Jun 05, 2001 at 07:33:55AM -0700, Dave Storrs wrote:
>       (By 'strictly', I think you mean 'all methods (etc) are declared
> explicitly in code, not generated by AUTOLOAD, etc'.  If I'm not
> understanding you correctly, please correct me.)

Yeah, pretty much.  I put together a proof-of-concept thingy to scan
for constructs which make code unpredictable here:
http://www.pobox.com/~schwern/src/B-Scan-0.01.tar.gz


>       Couldn't we still have a 'be-super-strict' flag that would throw
> warnings upon encountering a construct that would interfere with
> compile-time checking?  Make it be off by default, of course, but if
> people want Perl to help them check this kind of thing, it should be
> possible.

Yes, I'm just afraid this sort of thing would expand to engulf all of
Perl.  I'm also worried its scope would become far too large.

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.

This is, of course, a drastic example, but these sort of tricks go on
all the time in Perl.  Its probably not the cleanest OO style in the
universe, but its Perl's.  Any Perl OO idiom which breaks *formal*
encapsulation (as opposed to the informal style we usually keep) won't
work with strict, compile-time typing.  One or the other has to give.


I'm running into similar problems trying to put together some sort of
serviceable refactoring tools.  Perl's extreme maliability also means
extreme unpredictability, which makes things like strict typing and
automated refactoring less than 100% reliable.

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.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>    http://www.pobox.com/~schwern/
Perl6 Quality Assurance     <[EMAIL PROTECTED]>       Kwalitee Is Job One
Death follows me like a wee followey thing.
        -- Quakeman

Reply via email to