In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
Yet, does my proposal *force* this? Is it not possible for the magical
resource locator to coexist with a mechanism to allow local control?
Yes--through C<BEGIN> blocks and munging, you can get whatever
complicated, platform- or machine- or configuration-dependent behavior you
desire. But the *declarative* core structure of Perl should be
platform-indepedent. There shouldn't be anything in the language to
facilitate non-portable code, except just what is necessary to make
programs work given the reality of the existence of different platforms.
I think we have that already.
But what about
#use GetUserResponse in 'smpl_ui.pm'; # when debugging
use GetUserResponse in 'our_gui.pm';
Compile-time directives work better for that anyway. (You can have a
BEGIN block that checks an environment variable, so you don't have to edit
the code, or you can have "smpl_ui.pm" in a standard directory and in a
debug/ directory, and can just arrange to reorder @INC as necessary.)
True. Yet this implies all Perl programmers write for platform independence.
My experience has been that when I was using perl under windows, I had to use
ppm made available by ActiveState. Whereas for Linux, I could use CPAN
directly. This indicates a conversion procedure and rules of best practice
for software whose authors want it to be used cross-platform.
ppm versus the CPAN shell is a development environment difference, which
will always differ to some degree from platform to platform. We're
talking about *code* here, which should strive to be portable until it's
really necessary to be otherwise.
"Here's standard Perl--which won't work on $SOME_OS unless you add this
voudou" is somewhere we don't want to go. We want it to be easier to
write portable code than not.