[Development] QOptional

[Иван Комиссаров]

Actually, i plan to add Error class after (and if) QOptional will be merged. It requires big discussion too (i like idea if having an error code, but it would be better if we use a typed enum instead of int which should add 2nd template parameter - T and ErrorEnum). I don't want to discuss all of this now:)

Still, i would like to see both classes on Qt so i can use them in (future) ImageFormat API changes.

Иван Комиссаров

21 авг. 2014 г., в 15:29, private at bernhard-lindner.de написал(а):

> In our projects we are using a Result class that also exists as a  
> derived Outcome<T> class. That Result class consists of a boolean  
> (telling if an error occurred or not) and optional eror code and an  
> optional error message. The derived Outcome<T> class adds a value for  
> functions that do not only return error information but also a value  
> (in case of success).
> 
> In the beginning it was just a little helper to avoid nasty  
> GetLastError() and/or GetLastErrorString() methods. In a few months  
> these two classes turned out to be some of the most useful code we  
> ever added to our framework and currently they are used almost  
> everywhere as function results and became essential tools for writing  
> safe and readable code and were improved in many ways (e.g. as meta  
> types and for serialization).
> 
> Bot classes do NOT allow any default conversions (neither bool nor  
> value nor string) which made their usage a bit more verbose but  
> improved readability and safety a lot.
> 
> It seems to me that the main purpose of QOptional is similar (except  
> that QOptional couldn't carry an error message). I would (almost) kill  
> for having something like this officially supported in Qt.
> 
> Zitat von Иван Комиссаров <abbapoh at gmail.com>:
> 
>> Иван Комиссаров
>> 
>> 21 авг. 2014 г., в 14:37, Robert Knight <robertknight at gmail.com> написал(а):
>> 
>>> I've written a basic Option<T> class with a minimal interface to
>>> address the problems with bool* OK args Julien mentioned and found it
>>> useful - both
>>> in terms of communicating that something may not have a value and also
>>> it avoids the need for an invalid/null/empty version of T to be
>>> defined.
>>> 
>>> *However*, there is a problem when introducing this into an existing
>>> codebase in that it takes time to determine best practices and
>>> appropriate usages
>>> of an idiom like this, to figure out what methods such a class really
>>> needs and what can be left out or written as a separate utility
>>> function.
>>> 
>>> The problem with trying to introduce such a class to a foundational
>>> library like Qt first is that you don't have this experience and it
>>> isn't obvious what
>>> API is most important or what idioms will turn out to be widely used.
>>> This is how std::future ended up with some pretty basic problems in
>>> C++11.
>>> 
>>> I would suggest that a better approach would be to find a real app
>>> that is suffering the pains of the existing API - maybe Qt Creator?,
>>> introduce the class there first of all
>>> and then promote it once it has proven effective.
>> 
>> Good remark:) Actually, we're using plain c++ here at work and we  
>> have a simple maybe type (just bool and T with operator* -> and  
>> bool; no == or < > operators or different access methods). And you  
>> know what? We're using it much more often than you can imagine.  
>> Settings class has maybe<T> value<T>(string key) const; method. A  
>> lot of functions return maybe just because they can occasionally  
>> fail - when dealing with containers it's quite easy to get out of  
>> bounds; however crashing is not an option sometimes.
>> 
>> Also, we have an Error class which is {bool ok; union {T value,  
>> std::string errosString; }; } - this is used when function want to  
>> notify what is the exact problem.
>> 
>> With support of c++11 autos maybe and error classes appeared quite  
>> simple and intuitive way to deal with errors. Unlike exceptions that  
>> can be caught at any point of the code or error codes that are hard  
>> to check - you see what method can fail and you're forced to check  
>> if returned value is valid
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>