[Development] QOptional
Thiago Macieira
thiago.macieira at intel.com
Thu Aug 21 16:14:18 CEST 2014
On Thursday 21 August 2014 11:15:01 Julien Blanc wrote:
> Do you mean that you would change QSqlRecord::value to return, instead
> of a QVariant that can be null, a QVariant holding either an optional or
> a non-optional object ? I don’t see any advantages in doing so. That
> would make sense if you could get rid of the whole QVariant stuff, but
> that would imho need a complete redesign of QtSql. Otherwise, it’ll just
> add an extra layer, not providing any usefull feature (QVariant already
> does the job quite well in providing the nullability feature).
That's exactly what I am asking for. I'd like to deprecate QVariant's internal
nullability concept and make it rely on carrying a QOptional for a type to be
null.
If we don't do that, then QVariant: of a QOptional<QString> could be:
1) a null QVariant
2) a non-null QVariant containing a null (disengaged) QOptional
3) a non-null QVariant containing a non-null (engaged) null QString
4) a non-null QVariant containing a non-null (engaged) non-null QString
That's just non-sense and confusing to me. I'd like to collapse 1-3 as much as
possible.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list