we'll have to agree to disagree then - PRIVATE is a dirty word as far as I am concerned - I would also argue with your object property analogy

To quote hackers guide (though I don't claim this as my bible)

" ... Use LOCAL every time unl;ess you have a very specific reason not to. Then document the reason. If a subroutine needs to know the value of a variable in your calling routine, pass it explicitely as a parameter. This good programming practice is referred to as "loose coupling" and results in better documented, easier to maintain code.

Ken

>I guess you're a bundle of fun to work for. < gd&r >
>
>Seriously, PRIVATE is there to prevent stepping on other code's toes. It should be used in a blackbox environment to avoid unnecessary (IMO) parameter passing. If your blackbox system is reasonbly complicated (e.g several levels of program hierarchy), there is nothing wrong with creating private variables. It is synonymous with creating object properties and accessing them through the different levels of your code.
>
>>All,
>>
>>private vars are an exceptionally bad idea - for much of the same reasons that publics are - plus - if decoupling is a goal - there is nothing that breaks it worse than sharing live variables.
>>
>>I would suggest forgetting that the PRIVATE declaration even exists. I have all but fired programmers when I see a PRIVATE in their code...
>>
>>Ken
>>