[Development] Adding support for version number comparisons
thiago.macieira at intel.com
Tue May 13 18:38:03 CEST 2014
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
> 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
More information about the Development