associative arrays: iteration is finally here

[Leandro Lucarella]

Andrei Alexandrescu, el 29 de octubre a las 13:26 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 29 de octubre a las 12:33 me escribiste:
> >>Bill Baxter wrote:
> >>>>I think bool remove(key) is better than all other designs suggested so far.
> >>>I agree with the folks who say it's error-prone.  I can just see
> >>>myself now removing a key I know is in the dictionary and being
> >>>baffled when my program fails somewhere later on because I typed
> >>>aa.remove("theKey") when it should have been aa.remove("thekey").  I
> >>>knew it was there so I didn't want to clutter up my code with a check
> >>>for it.
> >>I don't find this reasonable. If you know removal must have
> >>succeeded, just type enforce(aa.remove("theKey")). I don't think
> >
> >I don't agree, this is like saying you should bound-check every array
> >access. I think it's nice to have safety by default.
> 
> remove from an associative array is not unsafe.

In the sense of "memory corruption" that's true. But your program will be
at least leaking memory if you thought the key was present in the AA (the
majority of the use cases for remove(), because come on, if you are
removing something is because you think there are very good chances that
the key is in the AA :). If your program then iterate the AA and there is
a key that it doesn't supposed to be there, it will blow in very original,
hard to track ways. What's the point of that?

If you want to remove something you're not sure that it really is in the
AA, you should use a safer method. Maybe try_remove(), or an extra
parameter to remove() or maybe just ask first if key in aa (but this have
an extra lookup, and I think that's the whole point that triggered this
discussion).

> >If you are expecting
> >to have an error, you will be extra careful to spell the key correctly.
> >This should cover the cases where you are distracted and not expecting any
> >errors.
> >
> >I think the check could be done in non-release mode only though, just
> >like bound checking.
> 
> Bounds checking is eliminated in release mode solely for efficiency
> reasons. There is no other good reason to eliminate checks. But in

Well, same for removing an inexistent key from an AA then :)

> the case of remove, the amount of work done is consistent enough to
> make a check negligible.

Ok, but make it an "Error", not an exception, so it can be used in nothrow
functions. Removing an nonexistent key from an AA should be a programming
error, except if you state in some way that you know that maybe the key is
not there (which should be rare).

> >>that's the overwhelmingly common case though, and if it's, say,
> >>about 50/50, then it's much more sensible to have a non-throwing
> >>primitive than a throwing one. And it looks like defining two
> >>primitives just to save a call to enforce is not a good design.
> >
> >This is one case where I think practicality beats purity, because the
> >whole point of throwing an exception is for the cases you don't expect it
> >to fail. Again, think of array bounds, you can force the programmer to add
> >lots of enforce() in the code and remove bound checking from the compiler.
> 
> I can't think of array bounds. The situations are completely unrelated.

I don't think they are *completely* unrelated. I agree is not exactly the
same because array bound error automatically imply memory corruption and
nonexistent key removal don't, but they are a bug in the vast majority of
the cases. At least this is my experience.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Fitter, happier, more productive, comfortable, not drinking too much,
regular exercise at the gym (3 days a week),
getting on better with your associate employee contemporaries,