<null> from nonexistent dictionary entry does not satisfy "≠"
-
I have a pretty big project and I was really confused for a while because values that weren't in my dictionaries weren't equal to a value but also weren't not equal to a value. Here's a screenshot:
The text input does not activate. It was a pretty annoying bug when I expected the pair of ifs to always run one or the other.
I'm fine with getting a null value, but I think it should just be not equal to any value so
if <null> ≠ xis always true. Whether
if <null> ≠ "<null>"is true doesn't matter to me, although some might find it useful.
Edit: I just remembered a similar issue was had previously, and using combine text with no value in the second slot and no space or new line added converts it to string.
-
@Jack8680 This problem probably stems from how Objective-C gives nil a status, and treats this with a degree of reverence and respect that few other languages ever have, provides dynamic binding and makes for graceful handling of void pointers and failures to find objects and their methods.
This makes it much safer to think in and use than C++, and a little slower.
One of the side effects is that non-existent key/value pairs don't return Null, they return nil, which might explain the results of your conditionals in your problem:
http://blog.alwawee.com/2014/11/19/check-nsdictionary-key-check-value-key-nil/
-
Sorry, forgot the important stuff. @Jack8680
Nil returns fail gracefully, often, in most situations, meaning your code probably never gets around to performing the conditional when the "Get Dictionary" value fails gracefully upon receiving a 'nil'.
EDIT: A possible solution. Create a flag (earlier) that fails to set if there is a nil return situation that stymies flow like this, and none of your conditionals fire. After your other logic, use yet another conditional to look at that flag's state and respond accordingly if it's apparent that your dictionary didn't have a key able to create a change to that flag.
I'm not explaining this well. I hope this makes some sense.
-
@Deeeds when I use the output in a text input behaviour as the default value it is literally <null>, but before that it's a null value which acts weird.
It does get to the conditional because I can put other behaviours under it that use the null value and they work.
I realise that traditionally you wouldn't want to continue after receiving a null value since it indicates an error, but in this specific case I want to. Because of my edit it's not a huge issue since I can convert the null to a string and then it does work in conditionals.
Personally I prefer games that glitch and try to continue rather than crash, although you'd want to do some error checking if you're creating important save files to ensure you don't accidentally corrupt them.
Edit: your edit would probably work too, now I'm wondering whether converting to string or checking two conditionals is more efficient.
-
@Jack8680 Sorry. I expressed it wrongly... it's not that it doesn't get to the conditionals, it's that the conditionals with a nil in them don't get performed. I edited the comment because I caught this, but a little too late.
You can read a bit more about nil here:
https://www.cocoawithlove.com/2008/06/doing-things-in-cocoa-with.htmlThis might help you see what I'm trying to say, but making a bit of a mess of.
I'm not an Objective-C fanboi. I quite like Swift. learning a lot about Swift meant learning some of the quirks of Objective-C. Part of that is how it deals with, in its design of and processes/paradigms and ways, using things like Optionals and its very unsafe (and fun) ways of permitting use of pure C having stemmed from Objective-C's ways and means contributing to much of the design of the APIs and Frameworks of iOS and macOS.
-
@Jack8680 Conditionals, whilst not cheap, are ok when they're in a decisive stage of things. Where they're a super bad idea is interrupting something that's got potential to be streamlined by SIMD or other processor and OS optimisations of iterative-like and predictive operations.
In this stage, when you're going to be doing conditionals anyways, there's not significant cost to running another one as branching is already occurring.
Handling strings is a lot of messing around. Even when you're only adding nothing to nothing. Lots of message sends and calls to do stuff. The extra conditionals, in this situation, are cheaper.
But both are incredibly efficient compared to drawing anything and the fill-rate problems that plague everything but the last two generations of Pro iPads.
The iPad Air 2, btw, has a prodigious capacity for handling geometry. That's its biggest win. The Pro's stepped back a little on geometry performance but gained massively in fill-rate performance.
-
@Deeeds interesting, I see what the issue is now.
Basically what I'd like is if the not equal operator is used with a null/nil value it always returns true (except maybe when both are null/nil).
This should be pretty doable with something like try/catch, right?
-
@Jack8680 said in <null> from nonexistent dictionary entry does not satisfy "≠":
This should be pretty doable with something like try/catch, right?
I suppose so. I'm not really super familiar with (ab)using error handling. I tend to design around whatever I learn about a language and get vocal about what I don't like, or expect that isn't there ;)
