SUGGESTION: perl-style associative arrays

[SSH]

I guess PHP probably has something similar, as may other scripting languages, but when I write stuff in perl I almost always end up using the hashed-arrays (associative arrays). I would love that AGS had such things as they are so handy.

For those that don't know them (I'm sure CJ would)... http://en.wikipedia.org/wiki/Associative_array

[scotch]

If AGS had a few more flexible data structures it'd make scripting so much more easy.  There's really no reason to have plain old static arrays in a scripting language, we don't care that much about speed here, compared to ease of use. Just about every scripting language I've seen has both associative arrays and dynamic arrays as fundemental data types (often with easy ways to write them in code, most common syntax seems to be [value, value, value] for a dynamic array, and {key: value, key: value} for a hash map.  I'm not sure how hard it'd be to add these things to AGS script but it's certainly one way I'd like to see it heading.

[Pumaman]

The main difficulty with this lies in the way AGS handles typing of variables.

In languages like PHP and Perl, everything is weakly typed so you can just declare a hashtable (or whatever it's called), and add anything as the key and value.
But in AGS, variables have types so this wouldn't work.

In C++ you use templates to create collections of this sort.
But AGS doesn't support templates, and can't reasonably be expected to do so since it's just a scripting language.

In C, you do an explicit cast to get things out of the collection.
But this is dangerous, because if you use the wrong cast then the program can crash, so I wouldn't want to allow this in AGS.

In Java/C#, you also do an explicit cast, but it does run-time type checking to make sure you use the correct one.
But in AGS, not everything is an object and variable types are not known at runtime (like in C).

So the problem boils down to the fact that AGS Script is a cross between C and Java, in a way that makes implementing this difficult.
It's not impossible by any means, but on the other hand it's not something trivial that I could add in an afternoon.

[SSH]

Well, even if it had a more-clumsy function-based interface (kinda like how LISP does it)...

Code: ags

Array myarray;
List mylist;

myarray.setq(key, value);
mylist=myarray.keys;
int i=0;
while (i<mylist.Length) {
  Display("Key %s Value %s", myList.Item(i), myarray.Lookup(mylist.Item(i)));
}

[Pumaman]

But even there, what type of variable is key and value?

I could very easily provide a standard collection class that was indexed with strings and contained Characters as values.
But that's only useful in particular situations, someone else would want a version that contained ints, or Hotspots, or whatever.

Being able to provide a generic implementation is actually rather tricky.

[SSH]

String index containing String can always be converted to ints or floats or chars by the usual conversion functions.

[RickJ]

unhandled_event()
[edit]
My bad SSH,  Sorry for putting this extra bit here.  I lost track of what I was doing and I thought this was the beta thread... *** deleted rest of topic

Associative Arrays
Why not make key and value just be strings?   You could use the AsInt property if you needed the value to be a numeric value (Is there an AsFloat property?).   There is not much point in the key being a numeric because you could just as easily use a normal array in that case.


Hehe, SSh you type faster than I do.  I think we are thinking the same thing about this?

[SSH]

I go for spee dover accuracy

[Scorpiorus]

But if we are talking about some specialized version then maybe a certain struct can be defined?

With "more-clumsy function-based interface", as SSH says:

struct Array {

   String keys[SIZE];
   String values[SIZE];

   import void Set (String Key, String Value);
   import String Get (String Key);

};


String Array::Get (String Key) {

   // find index by Key if possible

   // return values[index] if possible
}


void Array::Set (String Key, String Value) {

   // find index by Key or assign new index

   // set values[index] = Value
}


Now, if only we could have user-defined struct variables/pointers inside another struct.

Personally, I extensively use arrays to compensate for this but that makes the code quite a mess:

prefix_someArray[ someOtherArray[ handle ].handle ].value = ...

So, I'm with all kinds of good-old IDs and Handles at the moment; although it shadows all the beauty of OO stuff, to be honest.

Is there an AsFloat property?

Nope, as I'm aware of. Would be quite handy though.

[Gilbert]

I think float is currently more of a fancy addition than of much importantance and usefulness. However, this works (sloppily) I think:

Code: ags

float StringToFloat(String str){
  String ts="";
  char tempc;
  int coutn=0, pos;
  float tmpf;
  pos=str.Contains(".");
  if (pos<0) pos = str.Length;  
  while (coutn<pos){
    tempc=str.Chars[coutn];
    if (tempc>='0'&empc<='9'||tempc=='-'&s.Length==0) ts=ts.AppendChar(tempc);
    coutn++;
  }
  tmpf=IntToFloat(ts.AsInt);
  ts="";
  while (coutn<str.Length){
    tempc=str.Chars[coutn];
    if (tempc>='0'&empc<='9') ts=ts.AppendChar(tempc);
    coutn++;
  }
  tmpf=tmpf+(IntToFloat(ts.AsInt)/(Maths.RaiseToPower(10.0, IntToFloat(ts.Length))));
  return tmpf;  
}

[Kweepa]

I think float is currently more of a fancy addition than of much importantance and usefulness.

HERETIC!

Oh, a string-string map would be useful, I think.

[Gilbert]

HERETIC!

Why? you can even do stuff like sine and cosine without it.

[Pumaman]

String.AsFloat is a good point, that's missing at the moment.

--
Edit by strazer:

AGS v2.72 Beta 5:
* Added String.AsFloat property.
--

As for collections, would people agree then that a standard Hashtable-type class taking a String as its key and value would be useful?

[RickJ]

Yep, I'll go for it...

[Scorpiorus]

Seconded, especially if we could have them in structs.

[RickJ]

How about also a couple of methods() for quick and easy dumping a collection to/from a file?

[Pumaman]

Ok, I'll look into it.