[Development] Adding support for version number comparisons

[Thiago Macieira]

Em ter 13 maio 2014, às 18:26:32, Oswald Buddenhagen escreveu:
> On Tue, May 13, 2014 at 08:51:09AM -0700, Thiago Macieira wrote:
> > Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> > > the analogy is entirely bogus. the thresholds for usefulness and the
> > > user's ability to manipulate the input into something the qt code can
> > > work with are entirely different.
> > 
> > We disagree.
> 
> how helpful. how about substantiating your opinion?

I already have. I think that they are the same situation: we should make the 
Qt class work for input coming from the real world.

> the user has complete control over the input of qversion, and can apply
> any transformations which his use case may require. also, the effort
> would be quite trivial (qstring::replace(qregexp())).

But why should he if we can do it? I think the class should work out of the 
box. Qt is supposed to be easy to use.

We don't require people to write their own UTF-16 encoders before they use 
QString (unlike std::u16string). By the same token, I think QVersion should 
parse the user input.

If you think the QVersion constructor should be strict, I won't disagree. Then 
we should have a QVersion::fromUserInput, like the QUrl version, which is lax 
and has heuristics.

> > QLibraryInfo is *reporting* what was configured. The policy / semantic
> > decision was made at configure time. If we change the way we lay out our
> > files by changing configure, QLibraryInfo will report it.
> 
> well, it seems you don't even understand why what we are doing is wrong.
> bundles are supposed to be self-contained. this is *fundamentally*
> incompatible with the shared per-type locations qt's directory layout
> mandates.
> it's the perfect example for how putting policy into low-level classes
> is risky business.

I see what you mean. Indeed, all plugins are in a shared location, independent 
of which library loads them.

But that was a Qt Project decision, even if inherited from Qt 3, and simply 
due to us not foreseen the need there is today. The policy isn't in 
QLibraryInfo: it reflects the policy that was made by the Qt Project. If we 
change the policy, we change the class.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center