Good points, but with some caveats:

Unknown W. Brackets wrote:
> I would strongly argue that if you want such checking, you should have two versions of the library: one with -release, and one without.
> 
> For example, if I write a C program in release mode, and pass negative coordinates to a function that renders data to the screen (obviously, assuming it took 'int's), I would not be surprised if it crashed.  Nor would I complain to the makers of my compiler or library.  I am passing bad data.
> 
> It's clear you disagree; you want to catch every case of the bad data (even though, I'm entirely sure, there are places in your library where your OWN logic might cause bugs/crashes because of bad data.)

I must have made a serious mistake in the couching of that argument, since I'm not at all familiar with this angle. Sorry about that. The intent was to identify where [] syntax limits the expressiveness of the AA API; to the point where it trips over itself. Wanted to isolate that as a discussion point before making any suggestion as to how it might be resolved. Clearly, I failed pitifully in that goal.

As to catching a bad case of data, I'm much happier dealing with that on my own (rather than the compiler assuming it knows all). Given an ammended API, everything would be groovy.


> Anyway, your arguments are also flawed, as follows:

> 3. This is not true.  Having a bike, even if you need to use it to get gas sometimes, does not render your car redundant nor useless.  Even if gas prices are so high that you cannot use the car, that does not mean your wife would appreciate you selling it.  As argued elsewhere, the usage of the in statement does not necessitate using pointers to access the data at all.

Well stated; though this point was ammended to exclude multiple lookups as a reasonable alternative (as had originally been assumed). Hence, I feel it stands.

> 
> 4. Obviously, this is a bizarre conclusion to make.  For your uses, surely we might agree that the array-like syntax isn't commonly useful, but for other usage - indeed, for common usage - I really can't see such a wild statement being true.

Fair enough. I feel it's valid, since I don't see any point of using [] rvalues without using 'in' to avoid GPFs. Given the need for 'in', one doesn't need a redundant lookup via []. But, hey ~ if we were to get an additional method of the style that's apparently agreeable, then we'll have good reason to rejoice and to leap about with gay abandon:

# bool get(key, inout value); // or some equivalent twist on opArray()


> Furthermore, saying that having an array-style syntax is an invitation to writing bad code is something some can (and have) said about arrays, pointers, classes, class-less functions, couches, and generally everything else.  Yes, for your uses of it, an inexperienced novice might fall into bad habits with such syntax, but that does not again mean it applies everywhere.

Indeed <G>


Cheers.

Regan Heath wrote:
...
> I think we can and should avoid pointers.
> 
> I think the types of things we want to do can be broken into categories:
> 
> 1. 'check' for existance of an item.
> 2. 'check' for existance of an item and get it.
...
> 
> #1 - 'key in aa'
> leave it as is, or change it back to returning true/false.
> (NOCHANGE)
> 
> #2 - 'aa.finds(key,[out]value)'
> returns true/false and gets value if existing.
> (ADD)
> 
There should also be an 'bool aa.finds(key)' here since all of those oprations should be doable with methods (namely #1 too).

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

> I must have made a serious mistake in the couching of that argument, since I'm not at all familiar with this angle. Sorry about that. The intent was to identify where [] syntax limits the expressiveness of the AA API; to the point where it trips over itself. Wanted to isolate that as a discussion point before making any suggestion as to how it might be resolved. Clearly, I failed pitifully in that goal.

Perhaps it does.  But, this is contrasted with the fact that every major/popular C-like language that has associative arrays built in - C#, PHP, Perl, and others - uses the same syntax.  It may be well and good to explain how much healthier an apple is than candy, but that doesn't mean stores are going to replace their candy with apples.

In PHP, typically, you do something like this:

isset($var['associative key']) ? $var['associative key'] : 'fall back';

It's actually pretty ugly.  You'll also notice the double lookup. Otherwise, you may get an error - if associative key does not exist. Mind you, most people ignore this error (which leads to bugs.)  The PHP Group is actually considering some other sort of syntax, like ifsetor($var['associative key'], 'fall back'), which is much easier.

But, still, that's using (or maybe abusing) the array-style syntax.  On the other hand, this:

int val;
if (assoc.get("associative key", val))
   writef("assocative key: %d\n", val);

Looks like a class, yes, but not like an associative array.  I must say, while this has been the strength of C++ in many ways (as little as possible built in), it has also been (in my view) the reason why other languages, like even D, look so much better.

> Well stated; though this point was ammended to exclude multiple lookups as a reasonable alternative (as had originally been assumed). Hence, I feel it stands.

Only assuming the worst-case theory that multiple lookups will happen. I think it very reasonable to assume a compiler might cache/optimize out such double lookups, even if the current does not.

This reminds me of web browsers.  You may not know, but there is one from the W3C (which writes/wrote HTML itself.)  It's called Amaya.  It sucks.  In fact, I'm not sure it handles their own standards as well as Opera/Mozilla/Safari.

While DMD may be good (I especially like the compile times), time will only tell if it's the best compiler for D in the future.

-[Unknown]

"kris" <fu@bar.org> wrote in message news:dkmio5$1qtr$1@digitaldaemon.com...
> Sean Kelly wrote:
>>
>> 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
>
> If you mean adding an AA method similar to this:
>
> # bool get(key, inout value);
>
Yes something like this would be nice.
> ... then I'd fully agree with you. I think adding such a method is a good way to satisfy/resolve so many different requirements, and tastes. That particular signature avoids pointer usage and redundant lookups. An alternative would be to twist the array syntax some more, to do the same thing:
>
> # bool opArray(key, inout value);
>
>
> I do like how Walter changed 'in' (returning a pointer), since that can be useful for integration with C functions. But the AA[] rvalue, x = AA["foo"], change could be reverted in the presence of that new method.

"Unknown W. Brackets" <unknown@simplemachines.org> wrote
>
> In PHP, typically, you do something like this:
>
> isset($var['associative key']) ? $var['associative key'] : 'fall back';
>
> It's actually pretty ugly.  You'll also notice the double lookup. Otherwise, you may get an error - if associative key does not exist. Mind you, most people ignore this error (which leads to bugs.)  The PHP Group is actually considering some other sort of syntax, like ifsetor($var['associative key'], 'fall back'), which is much easier.

Interesting, Allthough scripting languages do have a different set of priorities.


> But, still, that's using (or maybe abusing) the array-style syntax.  On the other hand, this:
>
> int val;
> if (assoc.get("associative key", val))
>    writef("assocative key: %d\n", val);
>
> Looks like a class, yes, but not like an associative array.  I must say, while this has been the strength of C++ in many ways (as little as possible built in), it has also been (in my view) the reason why other languages, like even D, look so much better.

Perhaps. Though I'd argue that the functionality is more important than the way it looks. Maybe you'd prefer an array-style version of the above:

bool opIndex (key, inout value);
~~~~~~~~~~~~~~~~~~~~~
int val;

if ( assoc["key", val] )
     writef("key: %d\n", val);
~~~~~~~~~~~~~~~~~~~~~

Would that be more apropos?


> While DMD may be good (I especially like the compile times), time will only tell if it's the best compiler for D in the future.

True. Yet one must be able to depend on the feature-set across compiler implementations. This is a particularly sensitive concern since AAs are not part of the library; instead they are embedded within the language proper.

- Kris