develooper Front page | perl.perl5.porters | Postings from August 2001

Re: vstring guidance needed

Thread Previous | Thread Next
John Peacock
August 20, 2001 07:43
Re: vstring guidance needed
Message ID:
Nicholas Clark wrote:
> On Mon, Aug 20, 2001 at 09:21:01AM -0400, John Peacock wrote:
> > By design, actually.  I need a way to hint that the PV is actually a
> > version string, so my current code sets pNOK as a way to imply that
> > there is something special about this SV.  I assume that it would be a
> > bit presumptious of me to create a new flag VOK for a version string.
> Which routines do you need to hint to?

pp_ctl.c:pp_require (at line 3048) tests for SvNIOKp to decide whether 
to use the U8 path or the NV path for comparing Perl's version with the 
requested version.  Of course, I am going to remove the second path 
entirely, once I make sure that $] is a v-string.

> By setting pNOK (for a non overloaded SV) you will cause the value stored
> in the NV slot to be used in numerical contexts, rather than attempting a
> conversion of the string. (And as the string is an arbitrary collection of
> Unicode code points, that conversion won't make a sane value)

I thought if I set the private NOK flag then Perl wouldn't mess with 
the NV at all.  Do I need to overload the SV so that all comparisons 
will happen via my chosen interface.  If I don't set pNOK, how can I
know whether a given PV is a v-string or not?  I cannot use IsUTF as a
test, since "1.2.3" IS a UTF string (AFAIK).  I don't feel comfortable
just assuming that I have managed to capture all possible versions and
made them into v-strings.  I have already noticed some test code that

	$VERSION = "1.2";

but of course I could make the parser take that and use force_version()
just like "require" and "use" do (if I could understand the parser that
is ;~).

> > > Well, PV can be of an arbitrary length, while NV can't. That would speak
> > > against the NV. On the other hand, I don't see how "$scalar < v1.2.3"
> > > would work without an NV (or IV) equivalent of the vstring PV.
> >
> > This is a very good point, and one I wish I had thought of myself.  It
> > pretty much clinches it for me that v-strings have to be strings and
> > not numbers.  And, as far as "$scalar < v1.2.3" goes, I am going to
> > try and convince the parser to change that to "$scalar lt v1.2.3" on
> > the fly.
> Is this easier than documenting that the user should be using lt ?

Not easier, just trying to follow the Priciple of Least Suprise.  In
the current Perl, a user can use numeric comparisons and may get what
they want.  To rewrite the above in a more likely construct:

	package SomeMod;	
	$VERSION = v.1.2.3;

... some other module now

	package OtherMod;
	use SomeMod;
	if ( SomeMod::$VERSION > 1.2 )
	/* new enough to do something special */

I wanted to ensure that all comparisons happen as string comparisons,
rather than relying on the user to notice.  Of course, we can simply
make the numeric conversion fail with a noticible warning.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About