Marc, If you use a Object, and want to see it everywhere, you will use the public not ? No, no PUBLICs. There are several ways to eliminate PUBLICS. Here is one: ---------------------------------------------------------- ELIMINATING PUBLICS Here is a sample showing how ...
... since I only use database objects (e.g. oCustomer:name), and thus no variable type declaration is needed for field names. You can also eliminate PUBLICs using a database object. I think you are missing out on a lot by not working with OOP. I have taken old programs and reduced the code by more ...
To All I only use Publics for defining System wide user roles .. Read, Write, Supervisor and Admin... Statics work fine in a .prg with many functions .. specifically if you need to update a Static value within your .prg and have visibility ...
... in the oInvoice:New() method and it looks up the customer record and creates a oCustomer (singular) object inside the TInvoice class. I never use publics.
... are visible only within prg where they are declared The privates are visible from the moment they are declared onwards to their execution The publics are visible throughout the program Locals only within your function where they are declared I see that we can use all types of variables in ...
... End(), Display() are used in many other objects. Encapsulation: This object looks up it's own data (and saves it too) in the customer table. No PUBLICS or PRIVATES are used. To instanitate this object all you need one line of code and the CustNo. oCustomer:= TCustomer():New(cCustNo) That's it! ...
... that will override this behavior. I would change "PRIVATE oMail" to "LOCAL oMail" in your code. I never use PRIVATES or PUBLICS--too many issues. It forces you to encapsulate so you eliminate many hard to find bugs. Regards, James
Here is a sample showing how you can eliminate publics. One disadvantage of using publics is that they have to be declared in every routine that uses them or you will get compiler warnings. Of course, since publics are visible everywhere you always ...
... their permissions, but also any user preferences, and then you can access them easily anywhere. This also has allowed me to eliminate the use of PUBLICs anywhere in my programs. I used to get name conflicts with PUBLICs that created bugs that were very hard to find. No more. Regards, James
James Bott wrote:Here is a sample showing how you can eliminate publics. One disadvantage of using publics is that they have to be declared in every routine that uses them or you will get compiler warnings.
Here is a sample showing how you can eliminate publics. One disadvantage of using publics is that they have to be declared in every routine that uses them or you will get compiler warnings. Of course, since publics are visible everywhere you always ...
... lenguaje compilado, puro, donde los simbolos y variable se reemplazan por su dirección en tiempo de compilación. De la misma forma que no existen PUBLICs ni PRIVATEs, me temo que eso no sería viable. Desconozco que problema quieres resolver con una macro, tal vez puedas usar metodos virtuales ...
... outside the funtion it's been declared and add it to the function parameters. Maybe I actually could do both. First your way, declaring all the publics at the top of the file, then I would only get warnings for undeclared locals. Once I got all those declared, then I could remove the MEMVAR ...
... but prefixing every public var use is going require probably tens of thousands of prefixes. And I won't be able to tell if a function is using publics just from looking at the top of the function. Using the MEMVAR statement would only require one change per function and I get the documentation. ...
... but it appears that it won't solve the issue I am trying to solve. Moving the MEMVAR to the top of everything will prevent warnings for undeclared PUBLICs, but that is not what I need. I am trying to get warnings for every undeclared variable used in every function. This forces me to declare all ...