I've looked into this some more, and my current opinion is this not
clearly flexible.
The pragma/symbol/global system dates to back to when CGI scripts were
king, "applications" fit into a single file and name space, CGI.pm was
loaded once, and mod_perl was not in use.
Consider a modern web application which uses multiple packages. More
than one might "use CGI", the below script:
use v5.10;
package First;
use CGI '-xhtml';
sub first_foo {
my $q = CGI->new;
return $q->input();
}
package Second;
use CGI '-no_xhtml';
sub second_foo {
my $q = CGI->new;
return $q->input();
}
package main;
import First;
say First::first_foo();
import Second;
say Second::second_foo();
###
One package intends to set the "-no_xhtml" pragma, while another sets
the opposite. The result is that silently one pragma "wins" in both
cases.
Setting these values by global variables also has problems, a truly
global variable could affect another package at a distance that didn't
what the setting. And with global variables the intent is not always
clear or possible to express precisely. Did you intend to affect
everything everywhere, just the current package, or just the current
object?
Because of this inherent lack of clarity, it's hard to change with
confidence which controls how these are variables are managed. In the
cases reported here, are we certain for instance that there is only one
"use CGI" throughout the entire code-base... and only one "CGI->compile"
? Can we be certain that we are updating the behavior that correctly
represents what people expect about per-object values being reset and
how they related to global settings?
Here are my thoughts on addressing this:
- Using a framework like CGI::Application helps. It highly encourages
the application and plugins to access CGI through $self->query(). So
CGI.pm is "used" exactly once and any global changes can be declared
with "local" just before calling CGI->new in cgiapp_get_query().
- The documentation can be updated to be clearer about the best
practices for declaring global-scope and object-scope preferences,
as well as how to do deal with gotchas.
- CGI.pm could could consider adding object-scope pragmas something like
this: $q->pragmas('-no_xhtml -no_sticky'); That may be a horrible name
and interface, but the intent is there: a way to explicitly support
settings that are per-object.
Such a notion would be easy to manage the code for, and would provide
explicit clarity fo users.
If you still think there's some other global change to be made, I'd like
to see a reduced case example that triggers so that we understand
exactly which case is being proposed to be changed.
