With all respect to Thiago opinion I coldnt agree with it. There is nothing
wrong at all with forwarding comparison of the values with the same data types
to original classes within universal coontainer like QVariant as mentioned in
the previous answer. However I agree that comparing uncomparable should lead to
qFatal.. Problem is that even if I support idea of clean and tidy architectures
and designs -main goal of the frameworks is to make life simple and easier to
the end user - developer.. I looked in 5.15 sources. Ok idea clear - compare
logic moved to virtual lessThen of the sortind model with QModelIndex's as
parameters. Thats exactly an approach i have in my code for now with all extra
switches to handle what was forgotten in QVariant implementation, but as for me
its not a way to go. QVariant is a class exists for ages in the Qt and it has
all the features even now to provide a decent way to compare typed related
objects it contains including custom implementations.As for me 5.15
implementation is not better, its just moving same code to other classes
provoking develor to extra inheritance or to copy paste this code to other
places where QVariant stored values requires comparation..Why on earth then not
to change this in existing branches used in production rather then declare that
its a bad desing. I am not even talking about QtScript which is also QVariant
based and where it was really convinient way to handle abstract types. I know
that answer probably will be that we deprecated QtScript decades ago, but again
up to me thats was one on the worsest decision made although its a bit other
subject.It would take 15-20 lines of code to add native comparations to already
existing classes to current QVariant which will make things consistent where of
course < operator is applicable but only answer received sounds more like... (
skipped due to probable violation of some rules).. ;)And as we started about
versions.. its nice to hear that something going to change in 5.15, 6.0 etc,
but are Qt developers really assume that stable production code will easily
'just go' over major branches to update or will start adjusting current designs
to potentially fullfil some guidelines of far away releases?
Well, if QVariant::canConvert() says right operand can be converted to type of
left, thenconvert and compare the result. If it can't convert, behavior should
be undefined andqFatal() should be called (or whatever Qt 5.15 prefers to do in
detectable cases ofundefined behavior).
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
