Sorry your browser is not supported!

Let's say I have a not simple data Type, an array or a structure (Type). So it would not easy to return the whole structure (Type) or is not possible because I have to return an errorcode or something else.

Example:

Type MyType
a as integer
b as integer
EndType

Function MyFunction(v1 as integer, v2 as MyTpe)
v2.a = v1
value = v2.b + 7
EndFunction value

// Main
q as MyType
g as integer

q.b = 5

g = MyFunction(8,q)

......

What do I have to do, if I wanted also "q"s a changed in memory?

So that I could use the function again.

g = MyFunction(8,q)

And g would hold now 5+(7)+7?

I don't want to make "q" global. And don't want to return the complete structure variable (Type) every time. I am thinking of referencing to the variable itself, so that it will be changed itself and not only a copy of it, what I later have to set my variable to it.

If you are interested in the complex problem, please look at this code. I used global variables, because I did not want to change the structure of the code to much from it's original c-code.
https://forum.thegamecreators.com/thread/219370

Thanks for help.

Kind regards, xaby.

Maybe the answer is here?
https://forum.thegamecreators.com/thread/219328

REF, I overlooked it.
https://www.appgamekit.com/documentation/guides/12_array_changes.htm

Thanks for help anyway. Kind regards.

You can also return a UDT as well from the function.

Or use global vars?

Non-const globals are evil and should be avoided as far as possible.

Yeah this used to be all the rage. Nowadays I think globals are fine for many use cases. Forcing stuff into limited scope just because of some OO type ideology just makes things harder.

That said, AppGameKit could use some kind of light-weight scoping approach for methods and variables. OK, you can create types and scope variables through that but not methods/functions..

Oh, I am not a fan of OO - at least not how it is implemented in most of the current languages. It makes for needlessly complex code with a ton of objects scattered around just to interface between two other objects. With the exception of abstract datatypes (like queues, stacks and so on) I think data should be data and code be code. Not wrap the two up into objects.

But even so working within mostly procedural programming - limiting scope of your data is a very good practice. It decouples you code, ensures only functions with permission to do so can make changes, it hinders name-space pollution and more. Though there are cases where non-const variables makes life easier. For instance a state type that you use all over the place. Transporting that around manually just introduce unneeded complexity.

I agree there should be the ability to create bulkheads in AGK. Something like objects might be a bit overkill - but there is an alternative keeping in line with Procedural Programming paradigm of AGK. Modularity. At the top of each file you define what module or package the code belongs to - then follows the import list for what other modules or packages that will be able to use functions / types from.

Like how it was done in modula-2 and how it is done today in Golang. It's very nice and practical. Allthough unlike in Modula-2, Go use a Public/Private distinction on functions and types in packgages. Only the public ones are reachable by other packages/modules. In Modula-2 anything in a package/module was reachable once it was imported in another package/module.

I used REF, and it worked like I wanted it to work.