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?
Advertising
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.
Trey
