[Development] isValid() as a property

[Alan Alpert]

On Fri, Nov 29, 2013 at 3:03 PM, Tony Van Eerd <tvaneerd at blackberry.com> wrote:
>>
>> On Fri, 29 Nov 2013, Tony Van Eerd wrote:
>>
>> > in the cases I am looking at, if isValid() == false, then all the
>> other
>> > properties are invalid, and return "", -1, etc.  It really does mean
>> the
>> > whole object is invalid.
>> >
>> > (except maybe an 'id', in the case of, say, a Battery object - the id
>> > telling you which battery, and then isValid() saying that battery
>> > doesn't (currently) exist.)
>>
>> Why not use exists, present, active or something like it?
>
> 'present' was in fact my first choice (for battery at least).  But since the behaviour seems to match that of isValid(), why not isValid()? If we could (ie if we didn't care about compatibility), would we rename all the other isValid() functions on existing Qt classes?  If not, what is the difference?
>
> If there is a difference, and a clear rule when to use isValid() and when not to, I'd be quite happy.  But I want to understand the difference first.

As I understand it, we want to use isValid in all those cases where
the behavior matches exactly - this makes the Qt APIs more memorable
and more guessable (used a previous class with this behavior? Just try
isValid, see if it compiles ;) ).

>> But a C++ object
>> for a physical object that does not exist... why is it there in the
>> first
>> place?
>
> Essentially because we don't throw exceptions in constructors.
>
>         BatteryInfo battery(5); // the 5th battery.
>         if (battery.exists())....

If you start on a QML API, a similar issue occurs. Because there's no
way to handle construction exceptions gracefully, you'd need to be
able to declare an object and then for error handling (which could
mean no backing object could be created) then they bind to a property
like this.

--
Alan Alpert