in reply to Re: Re: Distinguishing a v-string from something else
in thread Distinguishing a v-string from something else

v-strings are used by the VERSION argument in a use or require. You cannot pass anything else!

that is not correct.

#!/usr/bin/perl require 5.006_001; package vstring; our $VERSION = '1.0.1'; package number; our $VERSION = 1.34_001e-5; package string; our $VERSION = '1.2beta4a'; package main; print $vstring::VERSION, $/; print $number::VERSION, $/; print $string::VERSION, $/; ## prints: ## 1.01 ## 1.34001e-005 ## 1.2beta4a

don't use v-strings, there are alternatives.

~Particle *accelerates*

Replies are listed 'Best First'.
Re: Re^3: Distinguishing a v-string from something else
by John M. Dlugosz (Monsignor) on Dec 05, 2002 at 01:31 UTC
    That's not what I'm talking about. See Everything you wanted to know about Module Version Numbers and Checking, specifically,
    The thing between the module name and the list must be a v-string or numeric literal. Anything else is rejected by the parser, unlike the normal indirect-object syntax that can be overridden with braces even if it doesn't smell like an indirect object.

    For example, you cannot write:

    use VersionTest '1.2.3' qw/foo bar/; #string my $needed= v2.3.4; use VersionTest $needed qw/foo bar/; #not a literal
    A variable named $package::VERSION is just another scalar and you can do anything with it.

    For the require/use VERSION only (what you thought I meant?) to assert the perl version, it will take a float or a v-string to serve this purpose, and any other string including "1.2beta4a" as a module name instead. Using floats and the 3-digit convention, you are limited to the significance of the float (is that enough parts?).

    Throwing v-strings into the mix doesn't cause any more problems than having numbers and strings (both) available. If you define module's $VERSION="1.0.2"; and use the old-style import method for asserting the version desired 1.0.4, it will use == in the comparison and ignore everything after the 1.0 in both cases, causing a false "accept".

    here is a much better approach, IMHO, but that's not "built-in" to the semantics.

    Funny thing is, using the indirect object syntax is a bit of a hack anyway, since that's not directly fed to the import method. Maybe I should forget that and encourage a revival of the "old" method, passing the desired version as an argument to the import list?

    —John