(Auto-)Protected Procedure-Parameters

[Froggerprogger]

Atm the moment we must not write:

Code: Select all

Global myVar.l
Procedure Add2(myVar.l)
  ProcedureReturn myVar + 2
EndProcedure

Because of this we have to use strange Procedure-parameter-names e.g. p_myVar, and so on to not get into conflict when sharing a procedure or reusing it in another code.
When you share/reuse a procedure that contains a parameter named e.g. dir.s but this variable name is used somewhere else in the new code as a global variable, you have to substitute all the 'dir' inside the procedure or the new main code with a worse selfexplaining word.

Because of this I would prefer that parameters are always handled as protected variables.

Of course then you couldn't access a global variable of the same name , but that's no problem, because the coder of a procedure knows it's global name-environment and what for global vars he want to use, if some, but (s)he cannot know the global variable-name-environment used in another code, so this point rans more into a conflict than giving an advantage.

The shared-command could override this behaviour, even if then the parameter gets 'lost':

This should give 23:

Code: Select all

Global myVar.l
myVar = 999
Procedure Test(myVar.l)
  Debug myVar
EndProcedure
Test(23)

And this one 999:

Code: Select all

Global myVar.l
myVar = 999
Procedure Test(myVar.l)
  Shared myVar
  Debug myVar
EndProcedure
Test(23)

Does anybody agree ?
Or have I overlooked a handicap ?

[fweil]

...,

But does not the pointer / value system render all possibilities :

Code: Select all

Global MyVar.l

Procedure Test()
Shared myVar.l 
  Debug myVar 
EndProcedure 

Procedure Test1(LongAddress)
  Debug PeekL(LongAddress)
EndProcedure

myVar = 999 
Test()

myVar = 23
Test1(@MyVar)

or maybe I misunderstand you ?

Rgrds

[freak]

Why not use the 'Protected' keyword for that?

Timo

[Froggerprogger]

@fweil
I think it's not really an alternative to always overgive a value by reference.
And even then the problem persists!
Referring to your example - imagine: I want to implement your procedure 'Test1' into my code. -> Then I must not have a global variable named 'LongAddress' anywhere in my source, otherwise I would have to rename all of them either in your procedure or in my code around it.

So if I write a procedure that I want to share with others, or reuse it, I shouldn't use variable names such as "x, y1, a2, dir, val, left, filename, ..." All these easy names could give trouble when someone wants to implement it in his existing code and already have a global variable of this name - he would to change the variable names to get the code run - though my intention of the procedure is never to refer to anyone's global variables that I don't know.
So I wish it would be protected by default.

Then - if you would use consequently 'Protected' for all the other variables in your procedure, you could reuse it later absolutely failsafe and without correcting never intended stuff - while still using simple variable names as parameters. It'll be like a class in java

@freak
How ?
This doen't work (error: a parameter can't be a GLOBAL variable)

Code: Select all

Global myVal.l

Procedure Test(myVal.l)
  Protected myVal.l
EndProcedure

[fweil]

Well, I understand your point of view but felt satisfied using @ and * with protected, shared and global commands.

The way ürebasic does is something clear for me, closer to my brain than ever.

Don"t know what next releases will be about giving more possibilities for coding different ways.

[blueznl]

i second froggerprogger's request, defining a global should not invalidate naming scheme of procedure parameters

[oldefoxx]

I think I understand your point, but I don't feel it is as easily resoloved as you make it out to be.

First, the scope of Global means that the same variable can be used everywhere, except where redefined as Local. True, you could have one or more parameters that have the same name as a Global one, but that should mean that it just defaults to a local definition - as you know, a parameter is merely a local representation of whatever is passed to the procedure by the calling routine.

Of course you could argue that this invalidates your efforts to pass values back by using those Global references, but that would not make sence - you would have to argue on on hand that the procedure writer does not know what Globals are or might be in use, then take the position that the procedure writer now wants to set a Global reference that he would have to know about to use!

The only problem that I can see is that if the compiler will not let you use a Global name as the name of a parameter because it is Global in scope (instead of automatically redefining it as a local reference), then you could encounter a situation where you cannot just "drop" an existing library into your source code - although this does not effect compiled libraries and DLLs. since their internal names are not visible (actually, no longer exist, since they were resolved into memory references during their compilation process).

The big thing here is to understand the scope of Global. If you write a procedure as part of a library or executable, then Global is only Global to that library or executable. It takes some effort to make a library Global reference also Global with regard to any executable that calls routines in that library. It is even harder (and more conflictive) toi try and share Global references betweeen executables and DLLs, because this then presupposes that the various executables are going to also be sharing those Globals, which can be ruinous, since none of the executables will know what all the other executables are doing.

If you write a procedure for someone else to use, you don't want to rely on globals. If you write a library for someone else to use, Globals are okay, but those Globals are not automatically known to the programs being written to use that library. Those programs have to be modified to support any library Globals. Usually, you do not do this, because again, the interactions between the executable and the library procedures are not in full accord. You run the risk of corrupting your common memory store. In fact Windows tries hard to prevent programs from reading and writing into each others memory space to avoid these conflicts.

Instead, it is much safer (and more straightforward) to pass information via parameters. There is a finite number of parameters that can be passed in this manner, but the number of parameters needed for a given process is probably fairly small. For more elaborate efforts, it sometimes makes sence to create a structure and pass a reference to it instead. That way a procedure is able to "share" a variable or memory reference that may be Global in nature in the executing program - not the other way around.