On Tue, May 13, 2014 at 12:59:10PM -0500, Keith Gardner wrote:
> > but then there is also the semantical perspective. keith's last proposal
> > i saw considered only numerical segments specially.
>
> Did you intend to say suffix? What I wrote on May 11th spoke specifically
> to the suffix compare:
>
i mean much more than suffixes:
post-3.5.1 (fail, everything's a suffix)
4:2.4.5 (fail, colon was not a valid number separator last time i
checked)
r12345 (fail, you hardcoded only 'v' as a skippable prefix)
and these are just the examples i'd call "sane".
my point is that this class is becoming unreasonably complex for a
rather trivial thing, which only a fraction of the applications will
use.
imo, the cases which are fully under the user's control (internal
version checking) should be handled solely numerically (even without
considering any pre-releases), which basically means a minimalistic
semver(-like) implementation which can be fully inline (or even just a
collection of macros). in this segment, it is entirely unreasonable to
try to support existing users with bizarre versioning schemes, because
they most likely already have their own solutions. and new users can be
told to use the straight-forward system.
another potential user group would compare externally provided
versions, but typically the user would also know about the structure of
the version (why should they compare the versions of something they
don't even know what it is?), and they don't need any semantics except
for sensible sorting. natural compare with preprocessing is an entirely
reasonable approach to that. performance is entirely irrelevant here.
and it is quite a corner case.
the third group would actually want to sort file names, and putting any
semantics into it beyond natural compare would be anything between
pointless and counterproductive.
this is also a bit of a niche market: file dialogs/managers, but as it
happens, we actually have one of these.
anyway, i'm getting bored with this.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
