Variable with a value the same as the variable name

Hi,

I am not purposely trying to break things but this weird situation came up just because of an external database design :). Here is a simplified version of the code that reproduces the problem:

Code:

---

proc page1_section2_field2_click()       

        local a = "TableName"
        AddColumn(a)       

endproc


proc AddColumn(tableName)
       
        s = "alter table ipranges add column &tableName char(30)"
        &s
       
        //At this point tableName has been overwritten, I'm not sure with what but I suspect it
        //may be an empty string of 30 chrs       
endproc

---

I have tried with other combinations & it happens every time, the issue seems to be passing in the string value "TableName" to a variable with the name 'tableName'. If the value and variable name are different then all is ok.

Do you realize that in VFP and Lianja/VFP field names have a higher precedence than variables. So if you have a field called name and a variable called name the field will be looked up first.

It is common practice therefore to name variables prefixed with m_ e.g. m_name so as to avoid name clashes.

Lianja and VFP are data centric languages.

Please read the Lianja essentials doc to get a better understanding of this.

Hi,

I would never use "macro inside of macro" like that in my VFP days.
One macro too much.
Instead:

Code:

---

s = "alter table ipranges add column "+tableName+" char(30)"
&s

---

I was just doing it like this for convenience Josip, noted though thanks

Quote:

---

Originally Posted by josipradnik

Hi,

I would never use "macro inside of macro" like that in my VFP days.
One macro too much.
Instead:

Code:

---

s = "alter table ipranges add column "+tableName+" char(30)"
&s

---

---

Thanks Barry, I had read that document but didn't see anything about field/variable precedence...and I don't know VFP.

I think I get it though - if my current open table is 'table1' and it has a column 'firstname' then any reference to 'firstname' will actually return the current value of that column & if I have a variable called 'firstname' the column is being accessed instead of my variable.

I my case the column doesn't exist initially so my variable seems fine, as soon as the column is created then I am actually reading the column value, not my variable value so it gives the impression that the variable is being overwritten.

Further tests show that if I close the table & then I access my variable again it is fine (because I am now reading the variable again and not the field).


Sorry for the blurb but I just put this down for my own sanity and for anyone else that may not understand how this works.

I use textmerge() (as I've suggested before) in situations like this:

Code:

---

lcDDL = textmerge("alter table ipranges add column <<lcTableName>> char(30)")
&lcDDL

---

Also:

you can, in VFP and in Lianja, use m. before a variable to enforce the distinction between a variable and a field name. I (and many others from the old school) use l, p and g as a prefix to vars to indicate their scope (local, private, global). This creates another distinction. While I could concoct a context where a collision would occur, I've never had one happen in 25 years of using that naming method.

I also notice that you used in your function definition:

Code:

---

proc(a)

---

While this is allowed, if Lianja follows VFP on this, a will be declared private in that scenario. As a matter of housekeeping, I prefer the parameters to be local (what's said here, stays here). This is accomplished with the the LPARAMETERS statement:

Code:

---

procedure AddColumn
lParameters tcTableName

---

The t before cTableName is a naming convention that indicates "this is a local variable passed to this procedure," thus distinguishing it from a a local variable created in the procedure. As a matter of practice, I do not set t... vars to a different value than passed: makes debugging much easier to know what the value was when passed.

hth,

Hank

Thanks for all the info Hank & I agree totally with keeping all scope as local as possible as far as possible.

Just a note on your comment about 'proc(a) resulting in a private variable in that function' - I did some tests and it seems not to be the case. If my test below is sound then it looks like 'tcPassedIn1' is local to 'Test1' and not private:

Code:

---

proc page1_section2_field2_click()       
       
        local lcTest
       
        lcTest = "Original String"
        Test1(lcTest)

        MessageBox(lcTest, 0)

endproc


proc Test1(tcPassedIn1)
       
        tcPassedIn1 = "Var not overwritten"
       
        Test2(tcPassedIn1)
       
        MessageBox(tcPassedIn1, 0)
       
endproc

proc Test2(tcPassedIn2)
       
        tcPassedIn2 = "Var overwritten"
       
endproc

---

Parameters in the proc declaration are local as you point out.

This is not standard VFP, it's another useful extension that reduces typing.