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

Version String Comparisons Justification (was Re: [PATCH 2 of 3] $] is deprecated)

Thread Previous | Thread Next
From:
John Peacock
Date:
August 23, 2001 08:40
Subject:
Version String Comparisons Justification (was Re: [PATCH 2 of 3] $] is deprecated)
Message ID:
3B85219F.5980FAD7@rowman.com
Gurusamy Sarathy wrote:
> 
> Sorry for coming into thread thread late, but IMHO, we made a very
> good decision based on Larry's ideas that these so-called "v-strings"
> should be nothing but some syntax sugar to write what you can otherwise
> write using escapes (i.e. it is pure expressiveness, and no semantics).

I am just using the expressed values to unify version comparisons, as
strings, see below.

> If what you're saying above means that we're somehow differentiating
> these "v-strings" from regular strings, everywhere, I'd like to see some
> very good reasons why we're going this route.  Please realize that doing
> such a thing is tantamount to introducing a new basic type--it is a
> kludge to do it without making it a first class type any way you look
> at it, and it would be bloat to make it a first class type for something
> as relatively silly.

There is no need to make them anything other than what they are: strings
that sort such that v1.2.3 < v1.11.1.

> 
> I'm well aware of the minor internal magic that tacks on pNOK to pass a
> hint to the lexer that version checking is desired in require and use.
> Let's not extend this purely internal hack into the realms of user
> visibility without thinking it through, shall we?

This is only needed to support "use 5.6.1" vs. "use Foo::Bar" in 
pp_ctl:pp_require().  If 5.6.1 is an Unicode datapoint string (is that
really better than v-string?), then the user is requesting a check 
of Perl's version, not trying to load a module.  It is a hack, but
I cannot see a better way around it and at least it is the same hack 
that is already there.

> 
> IOW, I don't see (after a cursory examination of the thread so far)
> what problem is being solved by extending the semantics of "v-strings"
> (which BTW is not an official term because Larry didn't like it).  It
> seems we're overengineering it purely for the sake of hack-happiness
> here.  I'm ok with simply reorganizing the code to make it cleaner,
> but it seems to me that adding new semantics is fraught with peril.

OVERRIDING GOAL: make sure that all comparisons of versions happen in
a consistent fashion.  

This includes both "use/require 5.6.1;" and "use/require Foo::Bar 1.1" 
to be consistent.  Current code uses one method in pp_ctl, a different 
one in UNIVERSAL::VERSION, one in Exporter::require_version(), 
and one in CPAN.  Some use numeric comparisons always, sometimes, or
not at all.  Some use string comparisons if they detect v-strings.
The code in perl.c:perl_contruct() constructs a v-string but then
always sets SvUTF_on, even though the roughly similar code in 
toke.c:scan_num checks first to see if that is needed.

UNDERLYING IMPLEMENTATION: extract the code that creates Unicode
datapoint strings from toke.c and move it to util.c so it can be
used by other routines (this was the easy part).  Change the following
code to make use of that function:

    universal.c:XS_UNIVERSAL_VERSION() - uses sv_cmp full time
    pp_ctl.c:pp_require() - now does sv_cmp() unless handed a number
    perl.c:perl_contruct() - the bit that creates PL_patchlevel
    gv.c:Perl_gv_fetchpv() - remove depency on PL_patchlevel for $]

and along the way create a new macro SvVOK() to encapsulate testing
for a v-string.  If a better way than pNOK comes along, it only needs
to be changed here.

In addition, the following patches to core modules:

    Exporter::require_version(): uses UNIVERSAL::VERSION().
    CPAN (not tackled yet) - use Exporter::require_version()

As I already have a day job, it's going slowly.  I currently have
a Perl that builds and passes most tests successfully.  I think I am 
very close now, or at the very least, identified all of the important
core code that needs to be examined.

I'm really trying not to change things just to change things; I want
to consolidate the existing code to reuse the existing tokenizing 
routines and make the comparison of versions consistent.

John

p.s. if none of this code winds up being used, I do view thia as a
learning experience, so I won't be too bitter. ;~)

--
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About