Closed ache closed 9 years ago
I've bisected this back to 53651f23ca109e4ab503fdaa645d54eb235dc0b2 which seems to suggest it's not necessarily the import behaviour but rather the call to CGI->_reset_globals
that's maybe not doing the right thing. I'll see if i can fix this although i'm not sure it's that important given the behaviour is approaching 10years in age (The fix might just be documentation).
Given behavior is not equal to current one, so we can't treat it as 10 years old. Old one was to make CGI::Fast as drop-in CGI replacement, not as anything additional. In old code pragmas overwrite can't happens because this single line works there, so 'use CGI ...' was unneeded:
use CGI::Fast qw/ :standard -no_xhtml -nosticky /;
New way of separation of CGI::Fast as additional thing may be good but leads to unpleasant surprises, like this one or already discussed #11
To confirm my theory of old drop-in replacement way, this apparently incorrect code still works right now, so CGI::Fast reinitializes CGI with CGI::Fast own pragmas:
use CGI qw/ :standard /;
use CGI::Fast qw / -no_xhtml -nosticky /;
new CGI::Fast;
print header(), start_html();
OK, i bisected #11 back to 9537f90526c43e799c8693286c299c9849d6ddd2 so clearly having CGI::Fast import
call CGI import
explicitly is buggy.
Right, i've restored the behaviour of CGI::Fast to import functions of CGI into the caller's namespace in v4.13_04 of CGI.pm (which i have just uploaded to CPAN) - note the is a DEV release due to the ongoing testing of leejo/CGI.pm#162 . I've also uploaded an updated version of CGI::Fast with clarifying POD and a couple of extra regression tests for #11 and #12.
FYI leejo/CGI.pm@5f47d5799bb96245f445fdfd5f4a6d16334051e6 is the fix in CGI.pm
Hi. From the earlier thread you post as valid example:
This code drops at least -no_xhtml pragma (I don't check other pragmas, but it is possible that all of them are dropped), while the code with changed 'use' order
works normally. The rest of test code to make -no_xhtml loss visible is: