Multi-Dimensional Arrays

[cbk1994]

It would be great if there was a way to get all index out of a multi-dimensional array. I don't really know how to word this ...

For example,

PHP Code:

temp.staff = {
                    {"cbk1994", "Scripter"},
                    {"PepperTheCat", "Management"}
                  };

temp.staffIndex = staff.getIndexes[0].index(@ player.account);
if (staffIndex > -1) {
  temp.position = staff[staffIndex[1]];
  player.chat = "You are staff:" SPC position;
} 


Instead, something like this has to be used:

PHP Code:

temp.staff = {
                    {"cbk1994", "Scripter"},
                    {"PepperTheCat", "Management"}
                  };

temp.staffIndex = null;

for (temp.member : staff) {
  if (member[0] == player.account) {
    staffIndex = staff.index(@ member);
  }
}

if (staffIndex > -1) {
  temp.position = staff[staffIndex[1]];
  player.chat = "You are staff:" SPC position;
} 


I thought there was a way to do this, but Skyld didn't know of one, and neither did any of the other people I asked.

[WhiteDragon]

Not entirely sure, but just a note, it would probably make more sense to use a hash (TStaticVar/TGraalVar) in this case:

PHP Code:

temp.staff = new TStaticVar();
temp.staff.cbk1994 = "Scripter";
temp.staff.PepperTheCat = "Management";

temp.playerPosition = temp.staff.(@ player.account);
if (temp.playerPosition != null)
  player.chat = "You are staff:" SPC temp.playerPosition; 


[cbk1994]

Originally Posted by WhiteDragon

Not entirely sure, but just a note, it would probably make more sense to use a hash (TStaticVar/TGraalVar) in this case:

PHP Code:

temp.staff = new TStaticVar();
temp.staff.cbk1994 = "Scripter";
temp.staff.PepperTheCat = "Management";

temp.playerPosition = temp.staff.(@ player.account);
if (temp.playerPosition != null)
  player.chat = "You are staff:" SPC temp.playerPosition; 


Agreed, though there are still cases where this might be needed.

[Skyld]

Typically in languages like PHP, an associative array would be used for this purpose ($staff["Skyld"] = "Global Scripting Admin";) except GScript does not sport this functionality. About the best I can suggest is to use a TStaticVar-esque table like WhiteDragon suggested, since it's about the closest to an associative array as you'll get in GScript.

[Inverness]

I expect that a hash table is used for storing the variables of an object, so a TStaticVar is a good choice in that situation.

As I was typing that I just had an idea about associative arrays. I think that in the case of an object, 'a["b"]' would map to 'a.b'. This would allow people to use a more appropriate syntax so it is obvious the coder is using the object as an associative array. In the case where b is a number, it would map to 'a.index<b>' (without brackets).

Example:

staff = new TStaticVar();
staff.timeout = 5;
staff["timeout"] = 5; // same as the previous

staff.(@ "lol" @ 3) = "pancake";
staff["lol" @ 3] = "pancake"; // same as the previous, but clearer (imho)

staff[5] = "five";
echo("5: " @ staff.index5); // example of how number is mapped to variable name

[WhiteDragon]

I'm not a really a fan of the syntax you're suggesting Inverness. All subvariables are referenced the same way with all the objects, there is no reason to adopt that syntax simply because a few other languages use it.

Technically an Array is a subtype of a TStaticVar already, although I'm not sure if the engine changes how it handles them (hash, linked list, etc). I'm not sure if you could still access the variables with the subvariable syntax either, but their might be a (undocumented) way to.

[xXziroXx]

I made a thread about the same thing last week.

http://forums.graalonline.com/forums...ad.php?t=83824

[Inverness]

Originally Posted by WhiteDragon

I'm not a really a fan of the syntax you're suggesting Inverness. All subvariables are referenced the same way with all the objects, there is no reason to adopt that syntax simply because a few other languages use it.

Technically an Array is a subtype of a TStaticVar already, although I'm not sure if the engine changes how it handles them (hash, linked list, etc). I'm not sure if you could still access the variables with the subvariable syntax either, but their might be a (undocumented) way to.

This would apply to objects, not arrays. Technicalities are irrelevant in this case.

The new syntax would show how you intend to use the object. If we did it like this, then I would never have to use the ugly var.(@ "something") because you have a more proper way to mimic dynamic variables.

[WhiteDragon]

Originally Posted by Inverness

This would apply to objects, not arrays. Technicalities are irrelevant in this case.

I was talking about objects. The second paragraph was just something I was pointing out in addition.

Originally Posted by Inverness

The new syntax would show how you intend to use the object.

Originally Posted by Inverness

more proper way

You do realize that all of these statements are subjective? They can all be answered by this nifty statement I had in my post:

Originally Posted by WhiteDragon

there is no reason to adopt that syntax simply because a few other languages use it.

[Inverness]

Originally Posted by WhiteDragon

You do realize that all of these statements are subjective? They can all be answered by this nifty statement I had in my post:

Do you have a better syntax recommendation for showing the reader that you intend to use an object as an associative array, one that is an alternative to the current object.(@ "varname")?

Are you complaining about the syntax itself, or the suggestion?

[WhiteDragon]

Originally Posted by Inverness

Do you have a better syntax recommendation for showing the reader that you intend to use an object as an associative array, one that is an alternative to the current object.(@ "varname")?

Are you complaining about the syntax itself, or the suggestion?

The suggestion. Why should there be an alternate syntax?
An associative array is a mapping of series of keys to their values, which happens to be what a hash does.
The way Graal chooses to handle this is with subvariables. Introducing the alternate syntax would only make things more confusing and suggest that there is actually a difference between the syntaxes when there isn't.

[Inverness]

Originally Posted by WhiteDragon

Introducing the alternate syntax would only make things more confusing and suggest that there is actually a difference between the syntaxes when there isn't.

This is true, and I would prefer an actual associative array type, but Stefan is busy and I don't expect such a thing considering the lack of updates to Graal.

My suggestion was simply the easiest way to implement an associative array facade, of course I don't expect that to be implemented either.

[WhiteDragon]

Originally Posted by Inverness

This is true, and I would prefer an actual associative array type

Why? A hash is the most popular way to implement an associative array so we effectively already have them. All it would be is a syntax change.

[Inverness]

Originally Posted by WhiteDragon

Why? A hash is the most popular way to implement an associative array so we effectively already have them. All it would be is a syntax change.

Yes, I know it's simply a syntax change, but I dislike the whole dynamic variables thing, I think it's just bad form. In any other language you use a hash table for such things. The new syntax would simply be a facade for that, so it would be obvious you're trying to use the object for that purpose.

*shrug* It's not really important, was just a random idea.

[WhiteDragon]

Originally Posted by Inverness

*shrug* It's not really important, was just a random idea.

Keep you and your ideas off this forum, boy. :P

[Inverness]

Originally Posted by WhiteDragon

Keep you and your ideas off this forum, boy. :P

Typical democrat, all about free speech until it's someone or something you don't like. Made you look.

[Loriel]

Originally Posted by Inverness

Yes, I know it's simply a syntax change, but I dislike the whole dynamic variables thing, I think it's just bad form. In any other language you use a hash table for such things.

Most dynamic languages just do not make a difference between dynamic variables and hash tables, so I do not think this is bad form at all.

[Inverness]

Originally Posted by Loriel

Most dynamic languages just do not make a difference between dynamic variables and hash tables, so I do not think this is bad form at all.

I know what you mean, it's just the syntax that I've had issues with. I don't know of another language that lets you create variable names inline.

[Loriel]

Originally Posted by Inverness

I know what you mean, it's just the syntax that I've had issues with. I don't know of another language that lets you create variable names inline.

Javascript, Lua.
Edit: I am not sure anymore what you are refering to. Lua at least lets you do getfenv(1)[varname] = 42, equivalent to local varname = 42, I think.

[Inverness]

Originally Posted by Loriel

Javascript, Lua.
Edit: Obviously only as entries into a table, but that is what we did here, too.

That is different in syntax than doing something like obj.(@ "var").subvar in Graal, I abhor that.