Steven,

I will try to explain the reasons that publics are not good, but it is a very complex situation.

The problem is that publics have side effects that object properties and locals do not have. For example, look at the routines below.

* Build string for display on screen
dDate = {^2001/12/25}
cString = "Christmas is on "
cString2 = FormatDate(dDate,"C")
? cString + cString2
RETURN

* Format date
LPARAMETERS tdDate, tcFormat
DO CASE
   CASE tcFormat = "C"
      cString = CMONTH(tdDate) + " " + STR(DAY(tdDate))
...
ENDCASE
RETURN cString

Now what gets displayed by this code when run;

"November 11 November 11"

Why?

Now consider these changes

* Build string for display on screen
LOCAL cString, cString2
dDate = {^2001/12/25}
cString = "Christmas is on "
cString2 = FormatDate(dDate,"C")
? cString + cString2
RETURN

* Format date
LPARAMETERS tdDate, tcFormat
LOCAL cString
DO CASE
   CASE tcFormat = "C"
      cString = CMONTH(tdDate) + " " + STR(DAY(tdDate))
...
ENDCASE
RETURN cString

What gets displayed now?

"Today is November 11"

Which is what was wanted.

Why did the first one fail? Because the routines stepped on each others variables.

Now let's introduce the effect of a public in this mess. We need to add a clock to the screen so we come up with this.

* Clock
PUBLIC dDate
dDate = DateTime()
RETURN

and we alter our other progrms to use this new program

* Build string for display on screen
LOCAL cString, cString2
dDate = {^2001/12/25}
cString = "Christmas is on "
* update clock on screen

Clock()
WAIT WINDOW TTOT(dDate)

cString2 = FormatDate(dDate,"C")
? cString + cString2
RETURN

* Format date
LPARAMETERS tdDate, tcFormat
LOCAL cString
DO CASE
   CASE tcFormat = "C"
      cString = CMONTH(tdDate) + " " + STR(DAY(tdDate))
...
ENDCASE
RETURN cString

So when is christmas in this code?

I hope this helps you to see how publics and privates can mess things up in a very subtle and difficult to debug way.