Can someone explain Var?

BlitzMax Forums/BlitzMax Beginners Area/Can someone explain Var?

Endive

(Posted 2015) [#1]

I realize why you would want to modify data in place.

But doesn't Var break encapsulation? I remember the bad old days when everything was global, and even the problems that could occur with passing by address in C.

Is this just used for speed reasons?

Do you encapsulate the broken encapsulation within an object to re-wrap it?

Midimaster

(Posted 2015) [#2]

In the case of VAR not the value of a variable is transfered into the fuction, but the pointer to the original variable. This does not disturbe encapsulation:

Local A%=2
Square A
Print A

Function Square (B% Var)
     B=B*B
End Function

You see that the variable name is not the same like the original variable.

VAR is used, when you have to return a bunch of results from a function. RETURN can only return one value:

Local A#=2, B#=4, C#=12
If Radical (A, B, C)=TRUE
     Print A + " " + B + " " + C
Else
     Print "Variable <0"
Endif

Function Radical (X# Var, Y# Var, Z# Var)
    If X<0 Return FALSE
    If Y<0 Return FALSE
    If Z<0 Return FALSE
    X=X^-2
    Y=Y^-2
    Z=Z^-2
   Return TRUE
End Function

Derron

(Posted 2015) [#3]

Var is only needed for "simple types" (int, string, float...) as all "objects" are already passed by reference.
So when modifying an object within a function, you modify the original object, no copied one.

bye
Ron

Kryzon

(Posted 2015) [#4]

Local a:Float

Function bla( value:Float Var )
     ...
End Function

If you know C++, Var as above is the same as this:

float a;

void bla( float& value )
{
     ...
}

Endive

(Posted 2015) [#5]

I still find it extremely questionable (yes, I know it's canon.) When I need to return multiple values I define an object type that contains the values I need and pass that.

Since objects are passed by reference in Blitzmax, the effect is the same, is it not?

I was a hardcore BASIC and machine language programmer before functions became widely available in those languages and having experienced debugging in the bad old days before hard encapsulation, the Var method really goes against my grain.

Is there any reason one would want to use Var instead of passing a packaged object and operating on that? Of course there's no *real* difference and of course Var is closer to the C way.

Henri

(Posted 2015) [#6]

Hi,

you can live perfectly fine without var when you are making a program (don't rememember the last time I used it), and as previously mentioned objects are passed by reference anyway. Var usually comes to play when you are making a more lowlevel library/mod etc. or interfacing with C.

-Henri

Derron

(Posted 2015) [#7]

If your wrappers just have to wrap 1-2 variables, then it might keep the namespace a bit more cleaner if you use "var" instead.

The benefit of passing a wrapper object is, that things are kept constant when extending classes - and overriding functions.

baseType.PassArgs(bla)
extendedType.PassArgs(bla)

compared to

baseType.PassArgs(x,y)
extendedType.PassArgs(x,y,z) 'not working
extendedType.PassArgsForExtendedType(x,y,z) 'working
anotherExtendedType.PassArgsForAnotherExtendedType(x,y,z,a) 'working too

bye
Ron