[Development] isValid() as a property
Is it common/uncommon/unheard-of to have a 'valid' property: Q_PROPERTY( bool valid READ isValid NOTIFY validChanged ) I'm thinking about classes like 'DeviceLocation' which would update with GPS changes, but at some point might just become invalid (or start invalid, until GPS turns on, etc). So should isValid() only be used for 'typical' cases of, like default-constructed value-types, or is it fine as a property? Thoughts? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
Imho isValid is fine, but generally I would suggest a more context specific name, i.e. locationKnown for example. Think about how much sense valid makes in the context of the caller code and see of you can find a better name perhaps. Simon Fra: Tony Van Eerd Sendt: 20:16 fredag 29. november 2013 Til: development@qt-project.org Emne: [Development] isValid() as a property Is it common/uncommon/unheard-of to have a 'valid' property: Q_PROPERTY( bool valid READ isValid NOTIFY validChanged ) I'm thinking about classes like 'DeviceLocation' which would update with GPS changes, but at some point might just become invalid (or start invalid, until GPS turns on, etc). So should isValid() only be used for 'typical' cases of, like default-constructed value-types, or is it fine as a property? Thoughts? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
Oh, the other thing I wanted to mention: 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.) ie it means isValid() in the same sense as all the other uses of isValid() in Qt classes. That's why I was leaning towards the same name. Although, yes, I was considering a different name per class, more context specific. From: Hausmann Simon [mailto:simon.hausm...@digia.com] Sent: Friday, November 29, 2013 2:20 PM To: Tony Van Eerd; development@qt-project.org Subject: SV: [Development] isValid() as a property Imho isValid is fine, but generally I would suggest a more context specific name, i.e. locationKnown for example. Think about how much sense valid makes in the context of the caller code and see of you can find a better name perhaps. Simon Fra: Tony Van Eerd Sendt: 20:16 fredag 29. november 2013 Til: development@qt-project.org Emne: [Development] isValid() as a property Is it common/uncommon/unheard-of to have a 'valid' property: Q_PROPERTY( bool valid READ isValid NOTIFY validChanged ) I'm thinking about classes like 'DeviceLocation' which would update with GPS changes, but at some point might just become invalid (or start invalid, until GPS turns on, etc). So should isValid() only be used for 'typical' cases of, like default-constructed value-types, or is it fine as a property? Thoughts? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
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? But a C++ object for a physical object that does not exist... why is it there in the first place? Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
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. 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()) We could have a battery-manager that instead hands out the batteries (so never hands out an invalid one) but: - BatteryInfo is a QObject (for signals, like the battery level changing) and I'd prefer not to return allocated objects (and then need to deal with ownership). It would be fine if they were value-types, but they aren't. - even if the BatteryInfo started out existing, it could be removed while still running (on some devices) Harri. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
On Fri, Nov 29, 2013 at 3:03 PM, Tony Van Eerd tvane...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
