Olivier Goffart wrote:
> Jędrzej Nowacki wrote:
> > 1. Are we allowed to add new conversions?
> > The question is tricky because adding a new conversion is a behavior
> > change, as this code:
> > if (variant.canConvert(QMetaType::int)) ...
> > may work differently. If we add custom types into the mix, everything
> > is even more complex.
>
> I'd say yes, for sensible conversion
> You are right that it is a behaviour change, but i think it is worth changing
> it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an "nice to have"
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build time,
but it's fine to change int foo() { return 42; } to int foo() { return -1; } ?
> so Qt can know it and use it. For certain types we can do much better,
> because we can automatically convert some types. For example:
> QVector<char> -> QLinkedList<int>
QVector<char> v; v.append(130);
QLinkedList<int> l = /*some"Sensible"AutomatedConversion*/(v);
assert(l.first() == 130) ? "Depends" ?
> > A conversion may be arbitrary. For example, most of the conversions
> > to QString. Should "bool(false) -> QString" return "False", "0", "false"?
> > What about precision of, for example, "double -> QString" ?
> We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to "avoid to do it automatically, prefer to make it explicit".
Already now it's far too easy to make mistakes based on the "nice
and easy" QByteArray -> QVariant -> QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
Andre'
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
