"Mike Parker" <aldacron71@yahoo.com> wrote in message news:d0jmti$1noe$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>>>I disagree. An out of bounds array index is an exceptional case because the size of the array is, usually, a known quantity - i.e. all members of the set of numbers from 0...n are valid, and n *must* be known during the allocation of the array.
>>
>>
>> Dynamic arrays grow and shrink all the time. Same thing with adding and removing keys from an AA. The only difference (conceptually) is that dynamic arrays have a continuous block of integer keys. But I don't see why that matters.
>
> Maybe I'm missing something, but the only way in D for a dynamic array to grow or shrink is to set the length property, correct? That means the last index is always known - the index (n + 1) always points to an area of memory beyond the end of the array.
>
> I said in another post that the [] used by associative arrays causes people to view them in the same light as normal arrays.

This looks like pure supposition. Or at least I suppose it is. Do you have evidence to support this?

"Anders F Björklund" <afb@algonet.se> wrote in message news:d0jrgi$1u5h$1@digitaldaemon.com...
> Regan Heath wrote:
>
>> I think throwing an exception is better than returning type.init.
>
> Maybe, but remember that you can write non-OOP code in D too... :-)
>
> And I think such an Exception would be better off hidden in a HashMap class library, instead of in the core language spec ?
>
>> But wait, you say, it's not an invalid assumption, I _want_ the value _or_  type.init, to which I answer, use 'contains':
>>
>> aa.contains("bob",value);
>>
>> value is an 'out' parameter, and will be set to type.init.
>>
>> As long as 'contains' exists I will be happy.
>>
>> bool contains(KeyType key, out ValueType value);
>> bool contains(KeyType key);
>
> But that's how it works now ? Just using a pointer,
> instead of: a "boolean" (bit) and an out reference.

Come on. The pointer stuff is just a joke. A hack that'll make people question the sanity, or at least the intelligence, of the language designers. I can't believe you don't see that, never mind be concerned about it.

Regan Heath wrote:

>>> I think throwing an exception is better than returning type.init.
>>
>> Maybe, but remember that you can write non-OOP code in D too... :-)
> 
> Sure, however Exceptions are the proposed/recommended "D Error Handling  Solution"
>   http://www.digitalmars.com/d/errors.html

Yeah, we just different in opinion on whether missing keys are errors ?

If they are, then an exception is OK... Something like ArrayBoundsError.

>> And I think such an Exception would be better off hidden in a
>> HashMap class library, instead of in the core language spec ?
> 
> Why? What's the difference between a hashmap class library and built in  AA's?

Objects ? :-)

> In short I want to be able to say:
> 
> if (aa.contains("bob",value)) {
> }

I like the current aa["bob"] syntax, just don't like the side effect.

The above looks too much like a function call, to be a built-in op ?
But I'm all for discussing/improving the syntax of "in" and "delete"

--anders

Matthew wrote:

>>But that's how it works now ? Just using a pointer,
>>instead of: a "boolean" (bit) and an out reference.
> 
> Come on. The pointer stuff is just a joke. A hack that'll make people question the sanity, or at least the intelligence, of the language designers. I can't believe you don't see that, never mind be concerned about it.

I do see it. I think it was simpler when they were
separate (like in DMD before version 0.107, or in
the Map interface of the Java Collections library)

The current "in" expr is a performance hack, nothing else...
I actually prefer to not use the pointer, just like a "bool".
My point was just that if you want both-at-once, it's there ?


As long as D uses the C++ way of setting non-existant elements,
or if it will switch to the proposed way of throwing Exceptions,
I need to use to "in" before accessing the array as a workaround.

Otherwise I would use it after, *if* I cared about the difference...
(between keys that don't exist, and keys that map to the .init value)
It seems that other people are using AA's in other ways, so I let them.

--anders

Matthew wrote:

>>I said in another post that the [] used by associative arrays causes people to view them in the same light as normal arrays.
> 
> 
> This looks like pure supposition. Or at least I suppose it is. Do you have evidence to support this?
> 

Just some comments I have read in this thread, such as in one of your posts:

"I'd disagree with both of you that it is in any way appropriate for the [] to return a default in the case where an
entry does not exist."

Couple that with the fact that I have never heard anyone ask for exceptions to be thrown from Hashmap.get() in Java and you may see where I draw the conclusion. My interpretation is that when thinking of a Hashmap class vs. D's associative arrays one might have different expectations, even the functionality is conceptually the same - is Hashmap.get("key") not the same as aa["key"]?

Mike Parker wrote:
> Matthew wrote:
> 
>>> I said in another post that the [] used by associative arrays causes people to view them in the same light as normal arrays.
>>
>>
>>
>> This looks like pure supposition. Or at least I suppose it is. Do you have evidence to support this?
>>
> 
> Just some comments I have read in this thread, such as in one of your posts:
> 
> "I'd disagree with both of you that it is in any way appropriate for the [] to return a default in the case where an
> entry does not exist."

And from Anders (just so I don't single out Matthew!):

"I guess it boils down to whether you consider an
empty array to be full of valid lookups, or not...
To me, a dynamic array is full of .init values
so then it makes sense that associative arrays
should also be full of .init values as well."


> 
> Couple that with the fact that I have never heard anyone ask for exceptions to be thrown from Hashmap.get() in Java and you may see where I draw the conclusion. My interpretation is that when thinking of a Hashmap class vs. D's associative arrays one might have different expectations, even the functionality is conceptually the same - is Hashmap.get("key") not the same as aa["key"]?

On Tue, 08 Mar 2005 11:01:46 +0100, Anders F Björklund <afb@algonet.se> wrote:
> Regan Heath wrote:
>>> And I think such an Exception would be better off hidden in a
>>> HashMap class library, instead of in the core language spec ?
>>  Why? What's the difference between a hashmap class library and built in  AA's?
>
> Objects ? :-)

? I'm not following...

>> In short I want to be able to say:
>>  if (aa.contains("bob",value)) {
>> }
>
> I like the current aa["bob"] syntax, just don't like the side effect.

I like that syntax too, and I'll use it, but only if I'm 100% certain the key exists, otherwise I prefer and will use the 'contains' syntax.

> The above looks too much like a function call, to be a built-in op ?
> But I'm all for discussing/improving the syntax of "in" and "delete"

I like "in".
I think "delete" should be done as contains is done above, i.e.

aa.delete("bob");

or perhaps it should be called "remove"?

Regan

Regan Heath wrote:

>>>  Why? What's the difference between a hashmap class library and built  in  AA's?
>>
>> Objects ? :-)
> 
> ? I'm not following...

A class library implies that it would be using classes
(or structs, if you want to do C++ish performance hacks)
The built-in arrays are not classes, any more than
strings are, so they would not use the same syntax ?

For a HashMap library, then a "contains" method with
parameters is perfectly alright and could even throw
exceptions if the class library designer so wished...
But a built-in class is more about operators and such ?

>> The above looks too much like a function call, to be a built-in op ?
>> But I'm all for discussing/improving the syntax of "in" and "delete"
> 
> I like "in".

With the pointer and all ? Maybe one could tweak the
language so that "in" can return either/or, and not
require a cast to be assigned to a bool/bit variable...

Then you would only have to know about the "special feature"
when doing performance tricks to avoid any double lookups ?

> I think "delete" should be done as contains is done above, i.e.
> 
> aa.delete("bob");
> 
> or perhaps it should be called "remove"?

I'm not sure you could even use the "delete" keyword, if you wanted?
"remove" would work great for a library, along with get/put methods...

I think I will hack together a simple Object-storing Map/HashMap,
just to see what it would look like in D ? (much like my String)


Still think "out" to be a great pun. :-)

value = "bob" in aa; => aa.contains("bob",value);
value = "bob" out aa; => aa.remove("bob", value);

--anders

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsna9qiqv23k2f5@nrage.netwin.co.nz...
> On Tue, 08 Mar 2005 17:10:04 +0900, Mike Parker <aldacron71@yahoo.com> wrote:
>> Matthew wrote:
>>
>>> Same here. And trying to get a value out of an associative container that does not exist is exactly that, exceptional. (Or it certainly should be.)
>>
>> I just can't agree with this. A missing key is simply a missing key. See below.
>
> I'm with Matthew on this one. Assuming there is a method:
>   bool contains(KeyType key, out ValueType value);
>
> that returns true/false and sets value when found.
>
> Then array["key"] makes an assumption (that the key exists), and if it's false, that is an exception.

This proposal is pretty nice. At the risk of going even more off-topic we should add a method to remove an item from the AA instead of "abusing" delete. I had guessed before that the reason Walter chose to use delete was to avoid adding a method to AAs. But now there are two good methods to add to AAs and so I hope he considers sacrificing the aesthetic beauty of method-less AAs for them.

The "in" operator should stay since it would be annoying to have to pass a dummy value parameter just to see if a key is in the array.

So, my preferred AA api:
 bit opIn(Key key) // possibly return value* instead
 Value opIndex(Key key) // throws on missing key
 bit contains(Key key, out Value value)
 void remove(Key key) // ignores missing key
 ... rest as before except "delete" is removed...

This would make opIn the only obstacle to writing a user type that mimics builtin AAs.

-Ben

In article <d0isq0$p3n$1@digitaldaemon.com>, John Demme says...
>
>Here's a good example:
[... polymorphism bug example ...]

can you show the same without using global static functions
(I mean free standing functions)?

>
>This makes a lot of sense to me.

it's called polymorphism,
integral to OOP, we can't say D supports OOP until this is fixed.

I hope this doesn't no into early/late binding discussions.

Ant