since in both cases the scripter needs to add a check to make sure he is handling a meaningful value.
Not necessarily, I think in many cases it can be safe to assume that your map contains the key you are referencing. If there's a condition where the key might have been removed at some point, you should definitely check if it's contained in the map first.
If there is a design decision or constraint behind this behavior other than the "flexibility / potential for unexpected behavior" trade-off, I would be happy for another lesson in coding practice.
I am interested too, which is why my question to Veracity was simply "Why?" and I don't think I asked it in a rude way or anything.
On a historical note, referencing a non-existing key used to create that key in the map, associated with the default value. This behavior was partly changed in
r8775. I say partly because of the following:
So this script:
PHP:
record my_record
{
location my_loc;
}
my_record [ string ] my_map;
print( "Value: " + my_map[ "Non-existent key" ].my_loc );
print( "Count: " + my_map.count() );
outputs:
Ah, interesting history note, thanks. To me that seems to be even more error prone... If you remove an existing key from your example map based on a condition of some sort, by accidentally referencing
"Existing Key" later on, you're inadvertently causing that key to exist, later down the track you might do the right thing by checking if
my_map contains "Existing Key" and it's going to return
true (even though you had intended for the record to be removed from the map) but the value referenced by that key is going to be the default value, not the one you might've been expecting had the condition for key removal in the first place not been true.
Edit: Interesting post from Bale I noticed in the thread you linked to.
Once, long ago, I ran into an intractable bug that made absolutely no sense until I discovered what happens when I check a nonexistent map entry. Since then I've always been careful to check if the map contains the entry. While I've been as careful to avoid that problem as if I was tiptoeing around broken glass, I have never liked the fact that I always felt like I had to work around around the problem. I could deal with it, but it was icky. Even more icky is the fact that almost everyone needed to trip over the problem at least once before they learned to avoid it.
So it would seem some of the old-school ASH scriptwriters out there may have learned the hard way when it comes to assuming a map contains an entry, but in the case Bale refers to he seems to be talking about KoLmafia creating a map entry with the default value simply by referencing it (ie. the current behaviour for aggregate containing map keys). I think Bale would've learned the easy way had KoLmafia simply printed an error whenever this unintended map key referencing behaviour had occurred.
