March 07, 2005
Matthew wrote:

>>This was why I suggested the syntax "key out hash" to remove it... :-)
>>Seemed to make more sense than the current recycled "delete" keyword ?
> 
> Yeah. Using delete to remove an element from the AA is an unequivocal stink.
> It must die.

"delete" makes sense in Perl, where objects are instead DESTROYed ?
In D, with a hash full of object references or pointers, it doesn't.
And while "in" is a nice performance hack, it isn't very pretty... ?
(it made sense while it returned bit, but not really with a pointer)


Combining exists-in-AA and get-from-AA into one operation sounds
like a case of premature optimization, and just a workaround for
the confusing behaviour (horrible bug) of the hash[key] expression.
(my condoleances to C++'s map, if that is where the critter was born?)

Throwing an exception instead of just setting it would be just as bad,
I would still have to use the workaround: (key in aa) ? aa[key] : null


I'm used to http://java.sun.com/j2se/1.4.2/docs/api/java/util/Map.html:

> boolean containsKey(Object key);
> 
> Object  get(Object key);

But of course, that can only store full Classes and not primitive types.
(but get returns null, both for null values and for unexisting keys...)

Perl is similar, it also returns blank values on unexisting hash keys.
There you can use the "defined" operator to separate between the cases.


So for me, rather naturally, I want the same hash behaviour in D too ?
But D is not Java and D is not Perl, so I'll live with the workarounds.

I do think it would make sense to continue and equate "unset variable"
with ".init value", since that's what the rest of the D language uses.

--anders
March 07, 2005
IMHO, reading from AA by nonexisting key must not write any data to AA. Let it return default value, bu NO WRITE.

(Sorry for repeating, but i don't know other way s to change current D
implementation details)


March 07, 2005
On Mon, 7 Mar 2005 11:14:31 +0000 (UTC), novice2 <novice2_member@pathlink.com> wrote:
> IMHO, reading from AA by nonexisting key must not write any data to AA.
> Let it return default value, bu NO WRITE.
>
> (Sorry for repeating, but i don't know other way s to change current D
> implementation details)

This idea has it's own problems, primarily with value types, take 'int' for example:

int[char[]] array;
int value;

array["bob"] = 5;
value = array["fred"];

at this point value == 0, and we have no idea whether it existed in the AA or not. So, we have to use 'in' eg.

int[char[]] array;
int value;

array["bob"] = 5;
if ("fred" in array) {
  value = array["fred"];
}

but, now we're doing a double lookup.

So, to solve this, we return a pointer from 'in' (as we currently have) OR...

we use a method call, eg.

array.contains("fred",value);

which returns true/false, and sets value if found.

I cannot see why you'd want anything else.

Regan

March 07, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm9k23nq23k2f5@nrage.netwin.co.nz...
> On Mon, 7 Mar 2005 21:49:42 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>> There are three options:
>>
>>     1. return .init
>>     2. insert an element
>>     3. throw an exception
>>
>> 2. is what C++'s map does, which is quite a mistake (albeit one that  could be ameliorated, given C++'s (current)
>> greater
>> expressiveness).
>>
>> 1. is a huge mistake, and I guess that's why no language/library (or at  least none I'm aware of) has
>> taken that option. (The exception of sorts is Ruby, which returns nil.)
>>
>> IMO, 3. is the only sane solution.
>
> I dislike 3 also, it would require code like:
>
> Field f;
>
> try {
>   f = array["bob"];
> } catch (UnknownKeyException e) {
> }
>
> to get an item from an AA without a double lookup.

Not so. I propose only a few hours ago that in should be redefined to be a boolean, and we should add

    bool $aa$.lookup(in key, out value);

No double lookup.
No ambiguity.
Highly useful.
Highly efficient.



March 07, 2005
On Mon, 7 Mar 2005 22:25:31 +1100, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm9k23nq23k2f5@nrage.netwin.co.nz...
>> On Mon, 7 Mar 2005 21:49:42 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>>> There are three options:
>>>
>>>     1. return .init
>>>     2. insert an element
>>>     3. throw an exception
>>>
>>> 2. is what C++'s map does, which is quite a mistake (albeit one that  could be ameliorated, given C++'s (current)
>>> greater
>>> expressiveness).
>>>
>>> 1. is a huge mistake, and I guess that's why no language/library (or at  least none I'm aware of) has
>>> taken that option. (The exception of sorts is Ruby, which returns nil.)
>>>
>>> IMO, 3. is the only sane solution.
>>
>> I dislike 3 also, it would require code like:
>>
>> Field f;
>>
>> try {
>>   f = array["bob"];
>> } catch (UnknownKeyException e) {
>> }
>>
>> to get an item from an AA without a double lookup.
>
> Not so. I propose only a few hours ago that in should be redefined to be a boolean, and we should add

I saw that post, I proposed the same thing months ago, we're in agreeance then.
Where does the exception come into it?

Regan
March 07, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm9maon623k2f5@nrage.netwin.co.nz...
> On Mon, 7 Mar 2005 22:25:31 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message  news:opsm9k23nq23k2f5@nrage.netwin.co.nz...
>>> On Mon, 7 Mar 2005 21:49:42 +1100, Matthew <admin.hat@stlsoft.dot.org>   wrote:
>>>> There are three options:
>>>>
>>>>     1. return .init
>>>>     2. insert an element
>>>>     3. throw an exception
>>>>
>>>> 2. is what C++'s map does, which is quite a mistake (albeit one that   could be ameliorated, given C++'s (current)
>>>> greater
>>>> expressiveness).
>>>>
>>>> 1. is a huge mistake, and I guess that's why no language/library (or  at  least none I'm aware of) has
>>>> taken that option. (The exception of sorts is Ruby, which returns nil.)
>>>>
>>>> IMO, 3. is the only sane solution.
>>>
>>> I dislike 3 also, it would require code like:
>>>
>>> Field f;
>>>
>>> try {
>>>   f = array["bob"];
>>> } catch (UnknownKeyException e) {
>>> }
>>>
>>> to get an item from an AA without a double lookup.
>>
>> Not so. I propose only a few hours ago that in should be redefined to be  a boolean, and we should add
>
> I saw that post, I proposed the same thing months ago, we're in agreeance  then. Where does the exception come into it?

The exception only occurs when using the subscript operator and the item does not exist




March 07, 2005
>array.contains("fred",value);
>which returns true/false, and sets value if found.
>I cannot see why you'd want anything else.

Sorry for my inattentive post reading.

Yes.
array.contains() syntax looks pretty. And may be "value" param may be optional?

But NO WRITES to AA!


March 07, 2005
In article <d0hbh4$250h$1@digitaldaemon.com>, Matthew says...
>
>Excellent philosophy.
>
>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.
>
>There are three options:
>
>    1. return .init
>    2. insert an element
>    3. throw an exception

My vote would be for 3 since looking up a key that isn't in the array is the AA equivalent to indexing a dynamic array outside of its bounds. Since indexing out of bounds throws an exception (in debug mode) so should invalid key lookup.

Plus the exception that gets thrown should be general enough to cover both cases. I  had to invent such an exception for MinTL but I'd really really love to just reuse a general "illegal index" exception from std.

-Ben

ps - Matthew, did you have too much coffee today? Your posts are ... intense.


March 07, 2005
"Ben Hinkle" <Ben_member@pathlink.com> wrote in message news:d0hjq1$2d6t$1@digitaldaemon.com...
> In article <d0hbh4$250h$1@digitaldaemon.com>, Matthew says...
>>
>>Excellent philosophy.
>>
>>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.
>>
>>There are three options:
>>
>>    1. return .init
>>    2. insert an element
>>    3. throw an exception
>
> My vote would be for 3 since looking up a key that isn't in the array is the AA equivalent to indexing a dynamic array outside of its bounds. Since indexing out of bounds throws an exception (in debug mode) so should invalid key lookup.

Well said!

> Plus the exception that gets thrown should be general enough to cover both cases. I  had to invent such an exception for MinTL but I'd really really love to just reuse a general "illegal index" exception from std.

Well, that exception hierarchy refactoring effort's getting closer :-)

> -Ben
>
> ps - Matthew, did you have too much coffee today? Your posts are ... intense.

Well, I've had very little sleep in the last 48 hours, and I'm stupendously late in the preparation of the May instalment of my CUJ column - going to be about Open-RJ/D, which I've just sent (along with documentation!!!) to Walter - and I've released 7 libraries in the last two weeks, and I'm 3 weeks behind the most recent deadline for starting the writing of my next two books, and my last client's got *more* work for me.

So, I guess I'm probably being more than a little strange.

Sorry if it's getting old. Am off to grab some sleep now, so enjoy the cessation, and hope for a more sane barrage tomorrow. (Now that Open-RJ/D is done, I'll be busy on other things for a few days, so maybe the volume'll be down at least.)

Cheers

Matthew





March 07, 2005
Manfred Nowak wrote:
> Anders F Björklund <afb@algonet.se> wrote:
> 
> [...]
> 
>>I suggested that hash[key] should stay the h*ll away from
>>setting keys that don't exist and just return .init, but lots of
>>people hated it... 
> 
> [...]
> 
> I am on your side.

I agree. I have a very hard time trying to figure out how anyone ever could disagree with this! Hands off the key!

> However, I just believe in the psychlogical phenomenons of understanding. And one of them is, that most people once involved in a more complex piece of thinking and then understood it, just do not want to through it away, because they have invested energy into this understanding.

Heck, I wouldn't actually bet on Stroustrup being too happy with C++, but hey, he's gotta know this. I know a lot of guys who used to be averse to digital circuits, precisely because they had to throw away a lot of hard work learning the (inherently more complex) analog thinking. It pissed them off to see the young guys doing all kinds of wizardry in the back room, and impressing the crap out of the bosses -- with only having read a chip catalog. It was so wrong.

As to Stroustrup (I admire the guy, but he's so precisely in the middle of what you said!), it must be horrible for him, and the thousands (both with C++, or totally in other fields) of others, who've amassed a huge knowledge and who've become icons.

> Most people will not accept, that the right way to reason about it, is to conclude that because of the fact that they had to invest energy, the introduction of this feature prolonges the time of learning D and that this prolonging is only justified if the costs for it are payed back in the further run. 

Nothing so bad, that it doesn't have a silver lining too: during all times, precisely this fact has made it very hard for new ideas to become accepted. Looking at the whole, it may be just as well. Weren't the resistance "unduely hard", then a lot of half-worthy ideas would have got accepted -- before their downsdes had become scrutinized. (Most of us have already had a taste of this in IT: the Hype Of Du Jour comes and gets replaced, even before you get to the bookstore to buy the book on it.)

> Diminishing the costs is a major goal of the design of D. But I have never ever seen costs calculated.

I don't know any hard facts, say for D, except a gut feeling. For example, I'm an old man and I am horribly slow at writing code. It takes me a week to write something kids half my age whip up in an afternoon. (I just hope I have less bugs and the code is better thought out. What can I do. :-) And maybe, maybe takes less maintenance in the long run.)

Anyhow, with C++ (which I, after all am more familiar with, since many more moons back, than with D), I code at least 4 times slower. And the code is full of bugs.

The difference being that the bugs in my C++ code I blame on the language, whereas my D bugs are genuinely my own doing.