Michael G Schwern wrote:
On Wed, Sep 28, 2005 at 12:36:40PM -0400, John E. Malmberg wrote:
So then the VMS related choices for the lib/test/simple/t/create.t would be:
A. Re-write it to avoid the VMS specific issue, like the patch that you
posted earlier does.
Ahh, except it wasn't a VMS specific issue. It was automatic, mandatory,
exclusive write locking (something not exclusive to VMS, I think Win32 does
it) and a perl bug with buffering. I didn't have to add in any more code,
its a basic cross-platform compat issue.
Yes, but the locking is not "mandatory" by VMS, it is just the default
behavior. The users of existing Perls on VMS can turn it off by a
documented setting before running Perl, or they can put VMS specific
code in their scripts to do so, even though they would probably be
better off using VMS::Stdio instead.
So I guess what I'm saying here is I'm happy to code to the lowest common
denominator, or there is no intersection to do things like "if this
system has feature X, do Y". What I do not want is "if this *VMS* system
has feature X, do Y."
Unfortunately I can see no way to avoid the check for an OS name and
then if there then is an OS setting and maintain backwards compatibility
with older Perls where that OS setting was not even considered as a
possibility.
Again, without seeing the actual changes to the non-VMS modules I can't
really judge. Could you post them?
I will look for a few typical cases if I can find time this evening and
convert them from my 5.8.7 hacks to something that would use this
proposed VMS::Filespec.
If I could assume that a core module would never be used with an older
version of Perl than what it was shipped with, then the test would be
simpler to do.
As it is, I will need to test if a method exists, and if it does, use
the result from that method to determine if the existing VMS specific
behavior needs to change.
-John
[EMAIL PROTECTED]
Personal Opinion Only
