LiveCode Forums.

I am missing a method of variable pointers, so I have been using arrays instead:

put myVar into aKeyName
put theCalculation into myArray[aKeyName]

but this is not good in every situation, any other way?

Your two lines are exactly the same as:

put theCalculation into myArray[myVar]

What exactly are you trying to do and why?

Mark

Don't forget you can use "do format()" and "do merge()" to variabalize variables.

I just don't know how to do it without using an array.
I wish it where possible to put a value into a variable named via a variable pointer.

put "BagOne" into @variablePointer
put 15 into variablePointer

--which then should give me a variable named "BagOne" with a value of 15

Hi Toret,

@ is used in a different way.

You can put variable names into variables with the "do" command:
This will put "123" into the message box.

Best,

Mark

and then I have a handler that makes list like the following:

var2
var5
var37

Now I want a repeat that declares these names in my list as variables, how?

Dear ToreT,

Put the previous code inside a repeat loop. In short:
In these cases, however, I would use arrays instead.

Best regards,

Mark

This is something of the kind I have been doing, looping throug a text to find sertain numbers like "no2", "no15":

put "this is no2" & return & "this can be no15" & return into myText

repeat with i = 1 to the number of lines in myText
get matchText(line i of myText,"(no[0-9]+)", theText)
put theText & tab & "123" & return after theList
end repeat
split theList by return and tab --making an array

put theList[no15] -- just to check

--where: theList[no2] has value 123, theList[no15] has value 123 and so on

But I think there is some easier way in languages that have variable pointers

Dear Toret,

You can create the array at once:
Now, theText["no15"] should return "123", if your matchText patter is correct and the number of lines in myText counts 15 or more.

Faster would be:
Kindest regards,

Mark

Hi & thanks Mark,
I did not mention that I used the list to put it in a table field, then making the array. But I believe you even have a ready solution for putting the array into a field without even using the combine command!?

Anyhow, I would still like to know why we do not have variable pointers in Revolution?

Hi ToreT,

My guess is that we don't have variable pointers like you see in other languages because we don't need them in an xTalk language. There is a different kind of variable pointer, which lets you address a variable in a different handler, using @.

To put an array into a table, you will have to use the combine command. Don't forget to split it afterwards, to continue using it as an array or put the array into a temporary variable before combining it.

Best,

Mark

ToreT wrote:Anyhow, I would still like to know why we do not have variable pointers in Revolution?

In xTalks a whole lot the things you find in lower level languages simply don't exist. The whole idea of xTalk languages is to remove the need for the programmer to have to deal with such things as pointers, types, memory allocation and so-on.

The price is that we sometimes we don't have the same degree of control that lower level languages can give, but in most cases, there are xTalk ways of achieving things that are usually simpler and easier.

The xTalk premise is that a variable holds a value - which can be anything at all, a number, a million numbers, a string, an array, or whatever. Not only that, but we (the developers who use Revolution) don't know if a number that is currently in a variable is in memory as an int, a uint, a float, or a string. If we use it in a calculation, the engine gives it to us as a number, if we concatenate it with a string, the engine gives it to us as a string. This means, for instance, that pointer arithmetic makes no sense, since we could never know exactly what a pointer might point to.

Welcome to the revolution!

Best,

Mark

OK, let's leave it at that. Untill Revolution becomes a highrise and have to dig out a basement for the cars to park. My idea of a pointer was somwhat simple and limited, maybe not even like the low-level way.

Thanks again from
Tore