On Thu, 10 Feb 2005 00:19:05 +0100, Anders F Björklund <afb@algonet.se> wrote:
> Regan Heath wrote:
>
>>> But reading a value should not just create and store a blank one.
>>  I agree totally, I'm not arguing 'for' this behaviour at all. :)
>> Sorry if I missled.
>
> <phew>

:)

>>>>> You couldn't store "null" in in the old Java 1 class called Hashtable.
>>>>> Can't say it was ever a big problem ?
>>>>
>>>>  What did it do/return when you requested a non existant element?
>>>
>>> It returned null.
>>  Could it store basic types i.e. 'int'?
>
> Nope, like all collections in Java it can *only* handle Objects.
>
> That's why they have all the wrapper object types for primitives:
> Integer, Byte, Short, Long, Character, Float, Double, etc.
>
> And of course the String class is the default, for doing strings
> (doesn't really matter, since char[] is also an object in  Java!)
>
>
> For the JDBC interface, they do a double approach: there is one
> Object-returning method, and one for each of the primitive types -
> including a boolean "wasNull" function to check for null values.
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html
>
>
> Quite different. (D does *not* want such wrapper classes/methods)

With that, I agree.

>>> I fail to see why one wants a dummy new value or an exception.
>>  I don't want the former, I don't want the latter, however if they were our  only choices I'd choose the latter.
>
> "None of the above". :-)
>
>> As you've said we have other choices:
>>  - use 'in' and pointers.
>
> Pointers are optional.

Only if you're dealing with an object, or you don't mind the double lookup, right?

>> To me that seems contrary to the idea that a basic type is just that  basic, eg.
>>  int[char[]] aa;
>> int *p;
>> int v;
>>  //here we are trying to get the value of "fred" out of the aa without a  double lookup.
>> p = ("fred" in aa);
>> v = *p;
>>  //not too bad I admit, less verbose than
>> try {
>>   v = aa["fred"];
>> } catch(Exception e) {
>> }
>
> It doesn't work for all types of p, though. e.g. function delegates.

I suspect this is a bug.

>> Ahhh well, I guess all I'm saying is that:
>>  - I dislike the behaviour of v = aa["fred"] when "fred" does not exist, it  seems to be the greater of the evils.
>
> Mother of all evils.
>
>> - I dislike the soln we have to use to avoid a double lookup, but it  appears to be the lesser of the evils.
>
> For e.g. hashes of strings and Objects, just returning null is fine
>
> And that doesn't require a double lookup either... (except for "in")
>
> alias char[] str;
>
> str[str] aa;
> str v = aa["fred"];

I agree, however when it comes to generics (i.e. templates accepting AA's of both objects and basic types) you're force to use either a pointer or the double lookup.

Or you could write 2 versions of the template and specialise one to AA's of basic types. Not sure you can do this? And it seems contrary to the idea of 'generic' :)

Regan

Regan Heath wrote:
> 
> As you've said we have other choices:
>  - use 'in' and pointers.
> 
> To me that seems contrary to the idea that a basic type is just that  basic, eg.
> 
> int[char[]] aa;
> int *p;
> int v;
> 
> //here we are trying to get the value of "fred" out of the aa without a  double lookup.
> p = ("fred" in aa);
> v = *p;
> 
> //not too bad I admit, less verbose than
> try {
>   v = aa["fred"];
> } catch(Exception e) {
> }
> 
> Ahhh well, I guess all I'm saying is that:
> 
> - I dislike the behaviour of v = aa["fred"] when "fred" does not exist, it  seems to be the greater of the evils.
> 
> - I dislike the soln we have to use to avoid a double lookup, but it  appears to be the lesser of the evils.

Double lookup isn't necessary, as you have shown before.

I'm not sure if I really like the current behavior, but I've adjusted to it, so it doesn't bother me much. Now, if someone can come up with a better idea, that'll be even better. And, IMHO, exceptions are not a better idea.

_______________________
Carlos Santander Bernal

Anders F Björklund wrote:
> 
> It doesn't work for all types of p, though. e.g. function delegates.
> 

Are you referring to the thread "Q: how to do AA of delegates keyed by int?"? Because, at least in DMD, it works fine (as I shown in my reply in that thread).

_______________________
Carlos Santander Bernal

On Wed, 09 Feb 2005 18:51:53 -0500, Carlos Santander B. <csantander619@gmail.com> wrote:
> Regan Heath wrote:
>>  As you've said we have other choices:
>>  - use 'in' and pointers.
>>  To me that seems contrary to the idea that a basic type is just that  basic, eg.
>>  int[char[]] aa;
>> int *p;
>> int v;
>>  //here we are trying to get the value of "fred" out of the aa without a  double lookup.
>> p = ("fred" in aa);
>> v = *p;
>>  //not too bad I admit, less verbose than
>> try {
>>   v = aa["fred"];
>> } catch(Exception e) {
>> }
>>  Ahhh well, I guess all I'm saying is that:
>>  - I dislike the behaviour of v = aa["fred"] when "fred" does not exist, it  seems to be the greater of the evils.
>>  - I dislike the soln we have to use to avoid a double lookup, but it  appears to be the lesser of the evils.
>
> Double lookup isn't necessary, as you have shown before.

It's either a double lookup or a pointer for basic types.

> I'm not sure if I really like the current behavior, but I've adjusted to it, so it doesn't bother me much. Now, if someone can come up with a better idea, that'll be even better. And, IMHO, exceptions are not a better idea.

I agree. The current method of avoiding a double lookup is the best I've seen/thought of so far, but I still think it's 'yucky'.

Regan

Carlos Santander B. wrote:

>> It doesn't work for all types of p, though. e.g. function delegates.
> 
> Are you referring to the thread "Q: how to do AA of delegates keyed by int?"? Because, at least in DMD, it works fine (as I shown in my reply in that thread).

The latest DMD version (0.111, 0.112) is not available in GDC just yet.

--anders

On Thu, 10 Feb 2005 13:11:10 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> On Wed, 09 Feb 2005 18:51:53 -0500, Carlos Santander B. <csantander619@gmail.com> wrote:
>> Regan Heath wrote:
>>>  As you've said we have other choices:
>>>  - use 'in' and pointers.
>>>  To me that seems contrary to the idea that a basic type is just that  basic, eg.
>>>  int[char[]] aa;
>>> int *p;
>>> int v;
>>>  //here we are trying to get the value of "fred" out of the aa without a  double lookup.
>>> p = ("fred" in aa);
>>> v = *p;
>>>  //not too bad I admit, less verbose than
>>> try {
>>>   v = aa["fred"];
>>> } catch(Exception e) {
>>> }
>>>  Ahhh well, I guess all I'm saying is that:
>>>  - I dislike the behaviour of v = aa["fred"] when "fred" does not exist, it  seems to be the greater of the evils.
>>>  - I dislike the soln we have to use to avoid a double lookup, but it  appears to be the lesser of the evils.
>>
>> Double lookup isn't necessary, as you have shown before.
>
> It's either a double lookup or a pointer for basic types.
>
>> I'm not sure if I really like the current behavior, but I've adjusted to it, so it doesn't bother me much. Now, if someone can come up with a better idea, that'll be even better. And, IMHO, exceptions are not a better idea.
>
> I agree. The current method of avoiding a double lookup is the best I've seen/thought of so far, but I still think it's 'yucky'.

I guess I _could_ always use a template:

# import std.stdio;
#
# template find(Key, Value) {
#   bool find(in Value[Key] aa, in Key k, out Value v) {
#     Value *p = (k in aa);
#     if (p) v = *p;
#     return p != null;
#   }
# }
#
# void main() {
#   char[][char[]] aa;
#   char[] v;
#
#   //aa["regan"] = "test";
#   if (find!(char[],char[])(aa,"regan",v)) writefln("Found: ",v);
#   else writefln("Missing");
# }

In an ideal world it would look like:

if (aa.find("regan",v)) writefln("Found: ",v);
else writefln("Missing");

That would take:
 - some sort of type deduction, to remove the !(char[],char[])
 - the feature for arrays that allows:

void free_fn(char[] a);

to be called:

char[] a;
a.free_fn();

to also work with a template function as I've used.

Regan

Point is, if I do this:

...
char[int] test;

test[4] = 0;
return test[5];
...

I DO NOT want 0, because that would only confuse my programming.... that's all I meant.  If it has to return 0, it should set that too. Only way that makes sense, imho.

-[Unknown]


> Or do you mean you actually use hash[key] to set them ?

Unknown W. Brackets wrote:

> Point is, if I do this:
> 
> ...
> char[int] test;
> 
> test[4] = 0;
> return test[5];
> ...

How cute, char's don't get the .init value, but instead just a zero.

Now, that's.... totally useless:

> 	// Not found, create new elem
> 	//printf("create new one\n");
> 	e = cast(aaA *) cast(void*) new byte[aaA.sizeof + keysize + valuesize];
> 	memcpy(e + 1, pkey, keysize);
> 	e.hash = key_hash;
> 	*pe = e;

Would have more sense if it was .init ?

> I DO NOT want 0, because that would only confuse my programming.... that's all I meant.  If it has to return 0, it should set that too. Only way that makes sense, imho.

Had you gotten a '\xFF', maybe it could have worked for you too ?

But if you keep on relying on side effects like that,
I guess the current behaviour is working as you like.


Either way, calling opIndex on an array with a nonexisting
key should be defined and documentated properly. But out of
the three "plausible" solutions to what this op should do:

1) return 0 or -1 or null or some odd value like that
2) throw an exception, KeyNotFoundException or whatever
3) silently create a new zero-entry and return it

I find the current behaviour (3) to the *most* confusing...

--anders