"Dave" <Dave_member@pathlink.com> wrote ...
>>That's very true. But I think the problem here is actually the API? I
>>can't
>>find the thread right now, but there was one a few months back where we
>>were
>>asking Walter to revert back part of his prior change to the AA API, to
>>take
>>care of this issue and a couple of others. From what I recall, a concensus
>>was reached in terms of how it should really operate <*gasp*> but I think
>>by
>>that time Walter had already had enough, after changing the API once :)
>>
>>I'll try to locate the thread ~ since it would be good to eliminate this kind of concern (in the only place it apparently happens).
>>
>
> Is this part of it: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.dtl/136


No ~ I think there's been 4 or 5 threads since then :-)

The more recent concern was along these lines:

If you currently do an AA retrieval with a non-existing key, you'll get an exception. Thus you have to either use pointer syntax, trap the exception, or do a double-lookup via the use of "x in y" first. The problem is apparently compounded when different -release options are applied between a client-app and a library.

It's been suggested that a more capable lookup property be introduced for AAs (to support the [] syntax). This would look like

double [char[]] aa;
...
double x;
...
if (aa.get ("some key", x))
     // do something with x
else
    // do something else

or more concisely ~ add a get() property to AA's; and possibly a matching put() method for the sake of symmetry.

bool get (key, inout value);
void put (key, value);

These AA properties are simple, robust, intuitive, optimal, proven, succinct. No redundant lookups. No pointers anywhere to be seen. The get() method does not add an empty entry where one is not found, and does not need to throw exceptions.

I recall it was Regan Heath who first noted this API, perhaps 2 years back? The problem with current AA[] syntax is that it limits the expressiveness of the API ~ resulting in these ongoing posts about AA issues.


> If so, what if the AA implementation (as opposed to the API or the
> compiler) was
> changed so that code like the following would avoid a full-fledged double
> lookup?
>
> // if(key in array) {
> //    writefln("Key %s found and associated value is %s", key,
> array[key]);
> // }
>
> *Maybe* this could be done in the current implementation w/o a huge amount
> of
> work. The trick would be to make sure it was thread-safe and not add a
> bunch of
> overhead elsewhere, I think.

That does seem to be adding additional (tricky) work to ensure thread-safety, whereas the proposed get/put methods don't require anything like that? Walter had also suggested that a compiler might "notice" a double-lookup and then attempt optimization ~ of course, the compiler does not currently do that. It would surely be simpler to instead expose an API capable of handling the need, in a concise and able manner? Is there some rule that states AAs cannot have properties or methods?

Would be great if you'd be interested in adding these to the front-end ... <g>

- Kris