Yep ~ that would be great.

At the risk of being repetitive: I suspect AAs are trying to extract a bit too much out of  [] semantics ~ would be more productive to concentrate on a solid API rather than wringing out the array syntax; IMO. If one could attach properties to the compiler types (a la C#), then this would be a no-brainer.

AAs just need a more usable veneer, beyond the [] syntax ~ or be moved into templates instead.



"David Medlock" <noone@nowhere.com> wrote in message news:dk5rvr$1lbm$1@digitaldaemon.com...
> Kris wrote:
>> Ah. I just remembered that AA lookup's would insert an empty entry if one was not there already ... that behaviour has been exchanged for throwing an exception instead. Bleah.  As for idioms (mentioned below), in this case they can be optimized by the API rather than by the compiler.
>>
>> I believe there is a way, within D, to elegantly resolve these ongoing issues ... if you'd be open to change, then I'd be happy to make some suggestions <g>
>>
>> - Kris
>>
>>
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:djuj2d$2vvv$1@digitaldaemon.com...
>>
>>>"Kris" <fu@bar.com> wrote in message news:dju31o$2he6$1@digitaldaemon.com...
>>>
>>>> I think this particular change to AA's is just flat-out bogus
>>>
>>>Nobody had a nice word to say about the original implementation.
>>>
>>>Just write it as:
>>>
>>>   if (!(key in map))
>>>       map[key] = new Record;
>>>   r = map[key];
>>>   ...
>>>
>>>No, it isn't as efficient as the old way. But, like I said, the old way
>>>was
>>>called lots of unkind things <g>.
>>>
>>>It is possible that a future compiler may recognize the above as an idiom and rewrite it so the array lookup is done only once.
>>>
>>>
>>
>
> I will maintain my position that we should simply have a couple of builtins:
>
> Previous thread: http://www.digitalmars.com/d/archives/digitalmars/D/26554.html
>
> The builtin methods would handle all cases pretty easily:
>
>  bool get( in key, out value )
>  bool insert( in key, in value, out oldvalue )
>
>
> int[ char[] ] map;
>
> int n;
> if ( map.get( "Hello" , n ) ) { ..do something with n.. }
> else { ... no value in n ..  }
>
> if ( map.insert( "Hello", 200, n ) ) { .. previous value in n.. }
> else { .. no previous value was in map.. }
>
> Built in methods are overloadable whereas 'in' is not.
>
> -DavidM

"Kris" <fu@bar.com> wrote in message news:djumru$1a9$1@digitaldaemon.com...
> One issue here is the Access Violation

Yes, I'd like to fix that one. Can you post an example specifically for that? That's a separate issue from discussion of how it should work.

"Kris" <fu@bar.com> wrote in message news:djumru$1a9$1@digitaldaemon.com...
> although this new behaviour of
> throwing an exception is, I think, highly questionable. How did that get
by
> the wolves in the first place? <g>

It was repeatedly asked for.

> For example, I quite often use an AA to identify things as 'special' ~ URL schemes for example. If the scheme is not in the AA then it ain't special. The missing case is /not/ exceptional; instead it is actually the norm; I certainly don't wish to be catching exceptions for the normal case (from either a semantic or performance perspective). Nor do I wish to use
pointers
> for such usual, simplistic, cases.

That's why the 'in' version is there.

> OTOH, what you did with the 'in' keyword and pointers improved that aspect of it ~ if one wants to eliminate a potential double-lookup then one can
use
> the pointer syntax. Good!
>
> The problem here is that, at the same time, you changed the semantics of a simple lookup such that it now either requires pointer-syntax, the
overhead
> of try/catch, or yet another lookup. I think that was a mistake, and am
not
> too shy to say so :-)

I liked the previous syntax, and the way it worked, because it was efficient. But nobody, not one, spoke out in favor of it, and all heaped ridicule on it (and not completely without merit, I threw in the towel on it when it was pointed out that javascript didn't do it that way either, though I thought it did). Sorry if I'm a little sensitive about this <g>.

> Lastly, I /do/ actually have a kind word to say about the original implementation: other than the potential double-lookup, it was fast, and
it
> was simple. I still think AA's could/should have been handled via
templates
> when they came along, and could therefore have been treated as a library utility rather than being built into the compiler itself. Regardless, the usage model is now arguably slower and more complex than before ~ largely negating the effort of placing AA's within the compiler in the first
place.
> IMO.

For most uses of AAs, the lookups of existing entries one expects to be in there far outnumber the test/set style, so while it is a bit slower, it isn't appreciably.

Walter Bright wrote:
> "Kris" <fu@bar.com> wrote in message news:djumru$1a9$1@digitaldaemon.com...
> 
>>One issue here is the Access Violation
> 
> 
> Yes, I'd like to fix that one. Can you post an example specifically for
> that? That's a separate issue from discussion of how it should work.



There was an example in the original post, commented with the location of the GPF.

"kris" <fu@bar.org> wrote in message news:dkiu4q$20bq$1@digitaldaemon.com...
> Walter Bright wrote:
> > "Kris" <fu@bar.com> wrote in message
news:djumru$1a9$1@digitaldaemon.com...
> >
> >>One issue here is the Access Violation
> >
> >
> > Yes, I'd like to fix that one. Can you post an example specifically for that? That's a separate issue from discussion of how it should work.
> There was an example in the original post, commented with the location of the GPF.

I checked it out. The GPF happens when compiled with -release, the ArrayBoundsError without -release. That is as designed; the idea is similar for regular arrays. Array bounds checking is not done when -release is thrown, and you get whatever happens.

Walter Bright wrote:
> 
> I checked it out. The GPF happens when compiled with -release, the
> ArrayBoundsError without -release. That is as designed; the idea is similar
> for regular arrays. Array bounds checking is not done when -release is
> thrown, and you get whatever happens.

In the example provided, the lookup happened in a library. The library was -release, while the client code was not.

*cough*

You do realize, I hope, that the above approach dictates one /must/ use 'in' with AA's to avoid GPFs. I mean, if there might ever be a missing entry in an AA (of which is pretty much assured in the general case; esp within libraries) then one will end up with a GPF via -release

Thus, since 'in' requires the use of pointers, it holds that AA's require pointer-syntax to enable robust coding. I sincerely hope you see the irony in that, Walter?

I can somewhat understand your sensitivity in this regard; yet, the design appears to be a ticking bomb. Everyone ~ anyone ~ please help me to understand this is not the case?

I posit the following:

1) use of the array-syntax for AA lookups will produce a GPF if the entry does not exist. Please put aside -release for the moment ~ it is a red-herring

2) To avoid GPFs, one must use pointer-syntax in conjunction with the AA 'in' statement.

3) The usage of the AA 'in' statement renders the array-syntax lookup redundant, since one uses the pointer to reach the data instead.

4) Thus, the array-syntax is effectively worthless (and superfluous) for AA lookup, since pointer-syntax is a prerequisite to avoid GPFs. Further, the presence of AA array-syntax lookup is an invitation to write non-robust code.

On Sat, 05 Nov 2005 18:57:08 -0800, kris wrote:

> Walter Bright wrote:
>> 
>> I checked it out. The GPF happens when compiled with -release, the ArrayBoundsError without -release. That is as designed; the idea is similar for regular arrays. Array bounds checking is not done when -release is thrown, and you get whatever happens.
> 
> In the example provided, the lookup happened in a library. The library was -release, while the client code was not.
> 
> *cough*
> 
> You do realize, I hope, that the above approach dictates one /must/ use 'in' with AA's to avoid GPFs. I mean, if there might ever be a missing entry in an AA (of which is pretty much assured in the general case; esp within libraries) then one will end up with a GPF via -release

Huh? Of course!? Why would you think it wise to accept data from an unknown source without either validating it or accepting the consequences. To otherwise complain is not logical. It is parallel in concept to accepting a user's keyboard-entered data without checking that its okay to use.

In a library routine in which you open up it's API to external usage, one must either validate the parameters or accept the consequences of trying use unacceptable data.

> Thus, since 'in' requires the use of pointers, it holds that AA's require pointer-syntax to enable robust coding. I sincerely hope you see the irony in that, Walter?

It does not *require* one to use pointers. It is optional.

   if ( (UsrParm in MyArray) == null)
   {
       MyArray[UsrParm] = ArrayEntry = UsrData;
   }
   else
   {
       ArrayEntry = MyArray[UsrParm];
   }

Look! No pointers involved. And a good optimising D compiler might even be able to make this more efficient by caching the 'double' look up.

> I can somewhat understand your sensitivity in this regard; yet, the design appears to be a ticking bomb. Everyone ~ anyone ~ please help me to understand this is not the case?
> 
> I posit the following:
> 
> 1) use of the array-syntax for AA lookups will produce a GPF if the entry does not exist. Please put aside -release for the moment ~ it is a red-herring

Only on a 'get' access. Not on an 'enquiry' or 'set' access.

> 2) To avoid GPFs, one must use pointer-syntax in conjunction with the AA 'in' statement.

No so.

> 3) The usage of the AA 'in' statement renders the array-syntax lookup redundant, since one uses the pointer to reach the data instead.

Not so.

> 4) Thus, the array-syntax is effectively worthless (and superfluous) for AA lookup, since pointer-syntax is a prerequisite to avoid GPFs. Further, the presence of AA array-syntax lookup is an invitation to write non-robust code.

Not so.

What would have been nice is instead of Walter get all upset over people not liking his implementation, is to provide all four types of access.

   'enquiry' ::  Key in Array (returns pointer to Value or Null)
   'get'     ::  Value = Array[Key] (Gets the Value if it exists,
                                     error otherwise)
   'set'     ::  Array[Key] = Value (Sets/Replaces the Value. Creates if
                                     it doesn't exist.
   'initget' ::  Value = Array.initset(Key) (Gets the Value if it exists,
                                          otherwise creates an entry with
                                          .init values.)

Or any other equivalent syntax. The point is that there is no reason for the old behaviour to be totally removed from the language, just shifted away from being the default behaviour for 'Value = Array(Key)' syntax.

-- 
Derek Parnell
Melbourne, Australia
6/11/2005 5:41:50 PM

Hey Derek; I think you may have misunderstand the problem, so I'll attempt to clarify somewhat ~

Derek Parnell wrote:
> On Sat, 05 Nov 2005 18:57:08 -0800, kris wrote:
> 
> 
>>Walter Bright wrote:
>>
>>>I checked it out. The GPF happens when compiled with -release, the
>>>ArrayBoundsError without -release. That is as designed; the idea is similar
>>>for regular arrays. Array bounds checking is not done when -release is
>>>thrown, and you get whatever happens.
>>
>>In the example provided, the lookup happened in a library. The library was -release, while the client code was not.
>>
>>*cough*
>>
>>You do realize, I hope, that the above approach dictates one /must/ use 'in' with AA's to avoid GPFs. I mean, if there might ever be a missing entry in an AA (of which is pretty much assured in the general case; esp within libraries) then one will end up with a GPF via -release
> 
> 
> Huh? Of course!? Why would you think it wise to accept data from an unknown
> source without either validating it or accepting the consequences. To
> otherwise complain is not logical. It is parallel in concept to accepting a
> user's keyboard-entered data without checking that its okay to use.
> 
> In a library routine in which you open up it's API to external usage, one
> must either validate the parameters or accept the consequences of trying
> use unacceptable data.

I failed miserably to get your drift here. Hash tables are *not* like arrays. If they don't contain a key it is surely not a reason to GPF. Is it? We're talking about this code causing a GPF:

char[char[]] AA;

char[] s = AA["unforseen key"];  // GPF; can't check for a null return



> 
> 
>>Thus, since 'in' requires the use of pointers, it holds that AA's require pointer-syntax to enable robust coding. I sincerely hope you see the irony in that, Walter?
> 
> 
> It does not *require* one to use pointers. It is optional.
> 
>    if ( (UsrParm in MyArray) == null)
>    {
>        MyArray[UsrParm] = ArrayEntry = UsrData;
>    }
>    else
>    {
>        ArrayEntry = MyArray[UsrParm];
>    }
> 
> Look! No pointers involved. And a good optimising D compiler might even be
> able to make this more efficient by caching the 'double' look up.

Oh please!

Let's try to stay in the land of reason here. Yes, you can come up with all sort of ways to /make/ it work with /multiple/ lookups. Walter suggested a way to do it with three lookups instead. I know you appreciate optimal code paths, Derek, so can we sidestep this please? The above code has two lookups, where only one should be necessary. I sure hope you avoid multiple lookups within Build?

Since you're forcing the issue, let's change my posit to assert that gratuitous use of multiple lookups should be not be considered ideal?


>>I can somewhat understand your sensitivity in this regard; yet, the design appears to be a ticking bomb. Everyone ~ anyone ~ please help me to understand this is not the case?
>>
>>I posit the following:
>>
>>1) use of the array-syntax for AA lookups will produce a GPF if the entry does not exist. Please put aside -release for the moment ~ it is a red-herring
> 
> 
> Only on a 'get' access. Not on an 'enquiry' or 'set' access.

False. We're talking about array-syntax, and not 'in' syntax.
As above: char[] s = AA["unforseen key"];  // causes GPF


> 
> 
>>2) To avoid GPFs, one must use pointer-syntax in conjunction with the AA 'in' statement.
> 
> 
> No so.

Au contraire, my friend ~ unless you're prepared to perform unecessary multiple lookups. I don't consider redundant lookups to be relevant, and neither should anyone following this ridiculous saga.


>  
> 
>>3) The usage of the AA 'in' statement renders the array-syntax lookup redundant, since one uses the pointer to reach the data instead.
> 
> 
> Not so.

Certainly! Let's waste our time looking the entry up once again, just for jollies. And let's make sure the key is very, very long; and there's lot's of collisions in the hash table. Gratuitously wasting CPU cycles is surely a good thing.

>  
> 
>>4) Thus, the array-syntax is effectively worthless (and superfluous) for AA lookup, since pointer-syntax is a prerequisite to avoid GPFs. Further, the presence of AA array-syntax lookup is an invitation to write non-robust code.
> 
> 
> Not so.

Please re-read. Array-syntax lookup /by itself/ is borked. It has to be used in conjunction with 'in', and is therefore superfluous (since 'in' supplies the data anyway). Sure; you can lookup the AA again if you wish, but your counter-argument is redundant; just like the additional lookup. As noted, the existence of s=AA[], by itself, encourages rather fragile code. D requires pointer-syntax to lookup an AA entry without GPFing (redundant multiple lookups aside).

> 
> What would have been nice is instead of Walter get all upset over people
> not liking his implementation, is to provide all four types of access.
> 
>    'enquiry' ::  Key in Array (returns pointer to Value or Null)
>    'get'     ::  Value = Array[Key] (Gets the Value if it exists,
>                                      error otherwise)
>    'set'     ::  Array[Key] = Value (Sets/Replaces the Value. Creates if
>                                      it doesn't exist.
>    'initget' ::  Value = Array.initset(Key) (Gets the Value if it exists,
>                                           otherwise creates an entry with
>                                           .init values.)
> 
> Or any other equivalent syntax. The point is that there is no reason for
> the old behaviour to be totally removed from the language, just shifted
> away from being the default behaviour for 'Value = Array(Key)' syntax.
> 

The point of this is to expose the flaws in the current design. The counterpoints you've made are based entirely upon the use of thoroughly redundant additional lookups, so of what true value are they? I mean that sincerely, since I just can't see any value in multiple lookups where perfectly sound alternatives have been around for decades.

Do you want an alternative, robust, optimal API? It would be good to see AAs use a set of 'properties' instead, such as bool get("key", inout value) along with put(key, value) ~ which, BTW, has no pointer-syntax and is optimal in terms of avoiding those wholly redundant lookups.

The problem here is not the built-in AAs per se ~ instead, it's the force-fit of array-syntax as the API. Replace that with a set of 'properties' and there would be nothing to bitch and moan about. Right? Either that, or replace them with a template? One with the above functions?

What's truly extraordinary is that such a fundamental aspect of the language is still so unsound after all this time; and after so much worthless bickering. I mean, it's just a frickin' hash table for Bob's sake ... it ain't rocket science, and it sure as heck shouldn't be a political football.

Oh ~ perhaps AAs are not intended to be hash tables?

On Sun, 06 Nov 2005 00:49:26 -0800, kris wrote:

> Hey Derek; I think you may have misunderstand the problem, so I'll attempt to clarify somewhat ~

I don't believe that I have misunderstood "the problem" at all.

Currently in D, when one attempts to retrieve a non-existent element in an array, it causes a run-time error to occur. This applies to all array types: fixed-length, dynamic-length, and associative. (And yes, in the current D, an associative array is implemented as a hash-table.) The type of error depends on whether the -release switch has been used or not. If it has been used then a memory access violation occurs (ie. GPF under unix), otherwise if -release was not used an ArrayBoundsError exception is thrown.

The problem is that you don't like this behaviour for associative arrays.

I assume that when trying to fetch a non-existent element you would either like the element to be automatically created with .init value(s) and/or to return some initialized value, or to always throw an ArrayBoundsError regardless of the -release status. Which is it you'd like to see happen?

> Derek Parnell wrote:
>> On Sat, 05 Nov 2005 18:57:08 -0800, kris wrote:
>> 
>> 
>>>Walter Bright wrote:
>>>
>>>>I checked it out. The GPF happens when compiled with -release, the ArrayBoundsError without -release. That is as designed; the idea is similar for regular arrays. Array bounds checking is not done when -release is thrown, and you get whatever happens.
>>>
>>>In the example provided, the lookup happened in a library. The library was -release, while the client code was not.
>>>
>>>*cough*
>>>
>>>You do realize, I hope, that the above approach dictates one /must/ use 'in' with AA's to avoid GPFs. I mean, if there might ever be a missing entry in an AA (of which is pretty much assured in the general case; esp within libraries) then one will end up with a GPF via -release
>> 
>> 
>> Huh? Of course!? Why would you think it wise to accept data from an unknown source without either validating it or accepting the consequences. To otherwise complain is not logical. It is parallel in concept to accepting a user's keyboard-entered data without checking that its okay to use.
>> 
>> In a library routine in which you open up it's API to external usage, one must either validate the parameters or accept the consequences of trying use unacceptable data.
> 
> I failed miserably to get your drift here.

I apologize. Sometimes I'm not as good with words as I think I am.

I made the assumption that the library managed an AA, and that an public function was available that fetches data from that AA based on a supplied key in one of the parameters. I was just saying that if this is the case, then you'd be wise to validate the key data prior to fetching the AA based on the externally supplied key value.

> Hash tables are *not* like arrays. If they don't contain a key it is surely not a reason to GPF. Is it?

D's associative arrays are a specific type of hash table. The entries in the table are based on keys. And I agree, a GPF is only one of the possible implementation behaviors that are possible in response to a fetch attempt for an element that does not exist.

> We're talking about this code causing a GPF:
> 
> char[char[]] AA;
> 
> char[] s = AA["unforseen key"];  // GPF; can't check for a null return
> 

This is why you might benefit from Walter reestablishing this sort of behaviour in D - in addition to the current AA behaviour. Sophisticated coders such as yourself can use such facilities.

  char[] s = AA.initset("unforseen key");

Now you can check for s.length == 0 if that's important to you. Of course, that isn't always a perfect way of detecting unforseen key accesses.

In spite of the "double lookup" effect, I would still code it thus ...

  char[] s;
  if ("unforseen key" in AA)
     s = AA["unforseen key"];
  else
     -- some error processing if appropriate.

because it tells the reader of the code that it is possible to get bad keys and it implements a way to handle those unambiguously.

> 
>> 
>> 
>>>Thus, since 'in' requires the use of pointers, it holds that AA's require pointer-syntax to enable robust coding. I sincerely hope you see the irony in that, Walter?
>> 
>> 
>> It does not *require* one to use pointers. It is optional.
>> 
>>    if ( (UsrParm in MyArray) == null)
>>    {
>>        MyArray[UsrParm] = ArrayEntry = UsrData;
>>    }
>>    else
>>    {
>>        ArrayEntry = MyArray[UsrParm];
>>    }
>> 
>> Look! No pointers involved. And a good optimising D compiler might even be able to make this more efficient by caching the 'double' look up.
> 
> Oh please!
> 
> Let's try to stay in the land of reason here. Yes, you can come up with all sort of ways to /make/ it work with /multiple/ lookups. Walter suggested a way to do it with three lookups instead. I know you appreciate optimal code paths, Derek, so can we sidestep this please?

You might be misunderstanding me, now. I prize maintainable source code over runtime performance any day. If run time performance is really such an issue, code in assembler otherwise get back into the land of reason.

> The above code has two lookups, where only one should be necessary. I sure hope you avoid multiple lookups within Build?

Not if I can help it ;-) By the way, Build runs pretty fast in spite of me
'wasting' cycles checking for valid AA keys.

> Since you're forcing the issue, let's change my posit to assert that gratuitous use of multiple lookups should be not be considered ideal?
> 
> 
>>>I can somewhat understand your sensitivity in this regard; yet, the design appears to be a ticking bomb. Everyone ~ anyone ~ please help me to understand this is not the case?
>>>
>>>I posit the following:
>>>
>>>1) use of the array-syntax for AA lookups will produce a GPF if the entry does not exist. Please put aside -release for the moment ~ it is a red-herring
>> 
>> 
>> Only on a 'get' access. Not on an 'enquiry' or 'set' access.
> 
> False. We're talking about array-syntax, and not 'in' syntax. As above: char[] s = AA["unforseen key"];  // causes GPF

Isn't that what I said? Your code is performing a 'get' and not an 'enquiry'.

> 
>> 
>> 
>>>2) To avoid GPFs, one must use pointer-syntax in conjunction with the AA 'in' statement.
>> 
>> 
>> No so.
> 
> Au contraire, my friend ~ unless you're prepared to perform unecessary multiple lookups. I don't consider redundant lookups to be relevant, and neither should anyone following this ridiculous saga.

I must be one of the clowns then. I don't follow your philosophy anymore. Cost of the application over time is more important to me than trivial optimizations. Trivial in the sense that if it doesn't account for more than 5% of a program's execution time, why optimize it to death. My philosophy regard this is more along the lines of code it legibly first, and then profile it to locate areas that are worth optimizing.

> 
>> 
>> 
>>>3) The usage of the AA 'in' statement renders the array-syntax lookup redundant, since one uses the pointer to reach the data instead.
>> 
>> 
>> Not so.
> 
> Certainly! Let's waste our time looking the entry up once again, just for jollies. And let's make sure the key is very, very long; and there's lot's of collisions in the hash table. Gratuitously wasting CPU cycles is surely a good thing.

And you have measured this, right?

>> 
>> 
>>>4) Thus, the array-syntax is effectively worthless (and superfluous) for AA lookup, since pointer-syntax is a prerequisite to avoid GPFs. Further, the presence of AA array-syntax lookup is an invitation to write non-robust code.
>> 
>> 
>> Not so.
> 
> Please re-read. Array-syntax lookup /by itself/ is borked. It has to be used in conjunction with 'in', and is therefore superfluous (since 'in' supplies the data anyway).

Well not actually so. The "in" supplies the key and not the data. The data can be something totally different.

   real[char[]] AA;
   . . .

   real X;
   . . .
   if ("Some Key" in AA)
     X = AA["Some Key"];
   else
     -- Handle unknown key value.


> Sure; you can lookup the AA again if you wish, but your counter-argument is redundant; just like the additional lookup. As noted, the existence of s=AA[], by itself, encourages rather fragile code. D requires pointer-syntax to lookup an AA entry without GPFing (redundant multiple lookups aside).

D does not *require* pointer syntax. It is optional. But for completeness
here is the pointer version.

   real *q;
   q = "Some Key" in AA;
   if (a !is null)
     X = *q;
   else
     -- Handle unknown key value.

>> 
>> What would have been nice is instead of Walter get all upset over people not liking his implementation, is to provide all four types of access.
>> 
>>    'enquiry' ::  Key in Array (returns pointer to Value or Null)
>>    'get'     ::  Value = Array[Key] (Gets the Value if it exists,
>>                                      error otherwise)
>>    'set'     ::  Array[Key] = Value (Sets/Replaces the Value. Creates if
>>                                      it doesn't exist.
>>    'initget' ::  Value = Array.initset(Key) (Gets the Value if it exists,
>>                                           otherwise creates an entry with
>>                                           .init values.)
>> 
>> Or any other equivalent syntax. The point is that there is no reason for the old behaviour to be totally removed from the language, just shifted away from being the default behaviour for 'Value = Array(Key)' syntax.
>> 
> 
> The point of this is to expose the flaws in the current design. The counterpoints you've made are based entirely upon the use of thoroughly redundant additional lookups, so of what true value are they?

They have true value to me. They help me write code which can be read by other people because my intentions etc are made clearing in the code.

-- 
Derek Parnell
Melbourne, Australia
7/11/2005 2:17:21 AM

Walter Bright wrote:
> 
> I liked the previous syntax, and the way it worked, because it was
> efficient. But nobody, not one, spoke out in favor of it, and all heaped
> ridicule on it (and not completely without merit, I threw in the towel on it
> when it was pointed out that javascript didn't do it that way either, though
> I thought it did). Sorry if I'm a little sensitive about this <g>.

For what it's worth, I liked it too.  And I believe the C++ map worked this way (as justification for the design).

> For most uses of AAs, the lookups of existing entries one expects to be in
> there far outnumber the test/set style, so while it is a bit slower, it
> isn't appreciably.

I would have preferred leaving the existing syntax as-is and adding a new method called 'find' or some such that returned a pointer to the element or null if it doesn't exist.


Sean