RELEASE ALL LIKE Does not work !!!

[vilian]

When I run the program below I have different results depending on the version I use xHarbour

With xHarbour 1.1.0 appears NULL in two commands " ? cVar " .
With xHarbour 1.2.1 a NULL is displayed and then 10. The RELEASE ALL did not erase the contents of the variable!

Code: Select all

#include "FiveWin.ch"

FUNCTION Main()
PRIVATE cVar

   ? cVar
   cVar := 10

   RELEASE ALL LIKE cVar*

   ? cVar

RETURN nil
 

[James Bott]

Vilian,

I know this doesn't answer your problem, but I recommend never using privates. They generate bugs that are nightmares to find. I haven't used a private in more than 10 years.

Regards,
James

[Antonio Linares]

Vilian,

It seems as a xHarbour bug that should be reported in the xHarbour developers (and/or users) list, thanks

[vilian]

Antonio,

In harbour is ok ?

[AlexSchaft]

It's still an xharbour bug that has nothing to do with fivewin

[Antonio Linares]

Vilian,

In Harbour is also seems to fail.

Enrico, could you please test it too ? Thanks
We may need to report it to the Harbour mailing list too.

[Enrico Maria Giordano]

Problem confirmed and already reported to Harbour and xHarbour developers.

EMG

[Antonio Linares]

Enrico,

Thanks!

[Enrico Maria Giordano]

Already fixed in Harbour SVN.

EMG

[driessen]

James,

What do you use in stead of private variables ?

I use them a lot, and I never experienced any problem.

Thanks.

[Enrico Maria Giordano]

The only problem of PRIVATE and PUBLIC variables is their non-local scope. If you really need of a variable with non-local scope then you should first look at filewide STATIC variables.

EMG

[James Bott]

Michel,

>What do you use instead of private variables ?

The worst problems come from code where variables are undeclared as was the typical practice with Clipper. Here is an example.

Code: Select all

function main()
   use invoice  // contains field named "TOTAL"
   dowhatever()
return nil


function dowhatever()
   total:= 10
   msgInfo(total,"total")  // returns 7.00
return nil

Total in the above routine is returning the value in the fieldname TOTAL not the private named total. This is very confusing.

In this example we declare the variable as a LOCAL.

Code: Select all

function dowhatever()
   LOCAL total
   total:= 10
   msgInfo(total,"total")  // returns 10.00
return nil

Now total returns the expected amount.

There is almost always an open file in the current workarea so there is a constant risk the fieldnames will override privates. If you add a field to a file, it could end up breaking your code. Conversely, you could add a PRIVATE that could end up breaking your code. These kinds of bugs are very hard to find since they may only occur under certain circumstances (when a certain file is open and in the current workarea).

My solution? I program extensively using OOP. My apps are also classes.

Code: Select all

class TApp
   data ...
   method New()
   method Activate()
   ...
endclass

Then all you need to run your app is:

Code: Select all

function Main()
   TApp():new():activate()
return nil

So anywhere in the app I can refer to data of the class.

And I create business classes, like customer, item, invoice, etc. Within these classes I have all the needed code related to the real-world item. This includes all the data as class data so no privates are needed.

I also use LOCALs and declare all variables. I compile with the \w parameter to ensure that all variables are declared.

You can also eliminate publics. The App class handles some requirements and you can use a set/get function to store any variable you need. A set/get function stores the data as a STATIC.

Set the path.

path( cPath )

Get the path anywhere in your code.

cPath := path()

Regards,
James

[Enrico Maria Giordano]

The worst problems come from code where variables are undeclared as was the typical practice with Clipper.

This problem completely vanishes if you use /w compiler switch and proper declare the variables (what I always do):

Code: Select all

PRIVATE test
...

M -> test

The non-local scope problem still stands, though.

EMG

[James Bott]

Enrico,

>This problem completely vanishes if you use /w compiler switch and proper declare the variables (what I always do):

Yes. I did mention the problem was with undeclared variables (and I have seen lots of applications without a single declared variable).

Still, as you stated, privates are visible everywhere (even within FW and Harbour code) as long as they are in scope. So you have to worry about naming conflicts in all your code, even code that is unrelated to the Privates.

I just don't see any good reason to use Privates. I think they are only still available for backwards compatibility. There was a time when Clipper did not have LOCALs, STATICs, and OOP capability. Then PRIVATEs were needed. Not anymore.

Regards,
James