Conhecimentos indispensáveis - seja Clipper ou Harbour

por **JoséQuintas** » 02 Jan 2016 18:25

Vou abordar aqui só o que vi sobre falta de conhecimento, e que é muuuito importante.
É o básico pra tudo

variáveis: PUBLIC, PRIVATE, LOCAL, STATIC, THREAD* STATIC

funções/procedure: tradicional e STATIC

Compilação -w3 -es2: isso tem no Clipper!

É IMPORTANTE entender a diferença, muito programador ainda não aproveita as vantagens existentes.

por **JoséQuintas** » 02 Jan 2016 19:03

PUBLIC

Talvez o primeiro tipo de variável dos tempos do dBASE II, não lembro mais....

A variável é visível no aplicativo inteiro.
Se usar tudo PUBLIC, vai ter que ficar inventando nomes, até acabarem os nomes disponíveis.
Existe limite pra variáveis do tipo PUBLIC. Talvez no Harbour não, não sei dizer...

Ela fica visível no aplicativo inteiro.
Tá sempre ocupando memória.
Não se destrói sozinha.

Tem rotinas antigas que transportam os campos de arquivo pra variáveis, pra "facilitar" para programadores preguiçosos (chamar assim, porque NÃO É PRA USAR).
Na prática ela só complica, só facilita mesmo pra ler/salvar conteúdo, mas na minha opinião mais atrapalha do que ajuda.

FUNCTION LoadVars()
   FOR nCont = 1 TO FCount()
      cCampo := FIeldName( nCont )
     cVariavel := "M" + cCampo
      PUBLIC &cVariavel
      &cVariavel := &cCampo
  NEXT
   RETURN NIL

FUNCTION SaveVars()
   FOR nCont = 1 TO FCount()
      cCampo := FieldName( nCont )
      cVariavel := "M" + cCampo
      REPLACE &cCampo WITH &cVariavel
   NEXT
   RETURN NIL

Isso cria variáveis públicas para o arquivo aberto, rotinas pra ler e salvar, ok.
Mas É PROBLEMA.
Tá pensando que tá facilitando a vida, mas só está complicando.
Ainda mais no Clipper, que tem limite. Vai ter problemas e nem vai saber o porque.
Há limite na criação de variáveis públicas. Isso cria variáveis sem fim, então hora ou outra acaba em problema.

Fora isso, fica sem controle sobre que variáveis existem no fonte, ou nos fontes, já que pode criar em um lugar e usar em outro.

Também está aí justamente o problema de variável pública:
É uma variável que você cria não se sabe onde, e vai usar não se sabe onde.

O que acontece com seus fontes:
Passa a ter variáveis que você não sabe de onde vém, não pra onde vai, e não sabe nem mesmo se realmente precisa delas.
Entendeu o problema causado?
É manter variáveis que nunca se sabe se pode apagar do fonte ou não, porque pode usar ou não.
É dar chances para "desaprender".

Agora imagine 20 anos usando isso...
20 anos acostumado a ter variáveis que não sabe se pode apagar...
É acostumar a fontes que não sabe mexer, que tem coisas que não sabe se serve pra alguma coisa, etc.
É desaprender... é acostumar a ter coisas que não precisa no fonte... é desaprender tanto, que chega uma hora que acha que tá velho, que não entende mais nada...

Pois é... é difícil acreditar que um recurso da linguagem possa estragar o programador.
Ela é útil... sim, com certeza, há casos onde precisamos dela.
Mas não é uma regra. Não é pra usar sempre, é pra evitar, e usar somente quando não houver outra alternativa.

É exatamente isso.

E a variável pública pode ser criada em qualquer parte do aplicativo, qualquer rotina.
De repente, usando a rotina acima, vai acabar tendo nome repetido de variável pública sem perceber, afinal qualquer arquivo pode ter qualquer nome de campo e gerar qualquer nome de variável.

por **JoséQuintas** » 02 Jan 2016 19:42

PRIVATE

Foi a primeira variável com "vida limitada", e que se destrói automaticamente.
É o default do Clipper/Harbour.
Caso utilize variável PRIVATE no módulo principal, ela vai funcionar exatamente igual à pública.

Avanço bom pra época:

Já podia agrupar as variáveis públicas no programa principal.
Qualquer variável criada em módulo já se destrói automaticamente.
Funções já podem ter variáveis EXCLUSIVAS.

Muitos programadores não entenderam o "jeito" de tirar vantagem dela, e alguns não entendem até hoje.

Fugir um pouco do assunto, pra mostrar a vantagem dela, e falar um pouco de função.
Usando recursos do Clipper mais antigo...

x = 10
y = ""
? x, y
nomeMes( x )
? x, y
RETURN

FUNCTION NomeMes()
   IF x = 10
    y = "OUTUBRO"
   ENDIF
   RETURN

Isso acima funciona?
Funciona...
Mas vamos ao que é uma função: uma função é uma rotina que retorna alguma coisa. pode ou não receber valores pra fazer isso.

O que a função NomeMes() faz?
Usando a definição de função: ela serve pra retornar o mes, de acordo com o número que recebeu.

E na rotina acima? ela nem recebeu o número, e nem retornou o mes, então nem sequer atende à definição de função.
Ela tá como um remendo, um troço que foi colocado no fonte, talvez pensando só em economizar fonte, não no que realmente é uma função.
Problema: sempre que for usar, tem que usar variáveis x e y, não pode ser diferente.
Economizou fonte? economizou, mas não é pra isso que função serve.

por **JoséQuintas** » 02 Jan 2016 19:57

Vamos fazer a função do jeito que tem que ser:
Receber um valor e retornar um valor.
Com as primeras versões de Clipper, onde só existia PRIVATE

x = 10
y = ""
? x, y
y = nomeMes( x )
? x, y
RETURN

FUNCTION NomeMes
   PARAMETERS x
    IF x = 10
     x = "OUTUBRO"
    ENDIF
    RETURN X

Usar x foi proposital.
O que vai ser mostrado na tela?

10, ""
10, "OUTUBRO"

Ué... mas a função alterou o valor de x? porque continua 10?

Ao usar PARAMETERS, a variável se transforma em PRIVATE.
Também seria a mesma coisa se declarasse uma variável PRIVATE (não pra função funcionar, só no sentido de uma variável qualquer).
A variável PRIVATE tem vida dali pra frente.
Atenção ao "dali pra frente", não significa no horário dali pra frente, significa a partir daquele fonte, enquanto o fonte não terminar, e nos fontes que forem chamados a partir dele.

Ao declarar PRIVATE ou PARAMETERS (no caso da PROCEDURE/FUNCTION), uma nova variável é criada naquele momento.
Não importa se existia antes, é uma nova variável, independente da anterior.
Então a função criou sua própria variável X, usou, e no final ela é destruída.
Ela não tem nada a ver com a variável x que já existia.

Justamente aí se abriram possibilidades infinitas.
Passamos a poder criar funções com variáveis independentes, que não mexem com variáveis que já existem.
Dá pra usar nomes à vontade, sem causar interferência com nada.

Pois é... isto há mais de 20 anos atrás.
Até hoje tem gente que ainda não entendeu esse básico, de função ser totalmente independente dos demais fontes, e quais as vantagens disso.

por **JoséQuintas** » 02 Jan 2016 20:32

LOCAL

O problema de variáveis anteriores ao fonte foi resolvido com PRIVATE.
Mas e fontes chamados pela rotina?
Foi aí veio o Clipper 5.x, com as variáveis locais.

x = 10
y = ""
? x, y
y = nomeMes( x )
? x, y
RETURN

FUNCTION NomeMes( x )
  IF x = 10
  x = "OUTUBRO"
  ENDIF
  RETURN X

Qual a diferença?
A variável x que é parâmetro de função passou a ser LOCAL.
A vida dela agora é somente dentro da rotina, não existe fora da rotina, nem pra programas que a chamam, nem pra programas que ela chama.
Ela é totalmente isolada, só vale no fonte de NomeMes()

Agora sim, ao criar uma função, temos a certeza de nada interfere no que ela faz.
Qualquer nome pode ser usado.
É a garantia de funcionamento que faltava.

Isso foi criado no Clipper 5, em 1990, há 25 anos... (errei no outro post sobre a idade do PRIVATE)

Se não entende as vantagens de variáveis LOCAL sobre PUBLIC e PRIVATE, tá na hora de entender.

Não é invenção do Harbour, isso já tem 25 anos!!!!!
No mínimo, imagine que se criaram isso foi por um bom motivo.

É básico, é pra usar o tempo todo, não se preocupe em perder tempo aprendendo.
Na prática, não vai estar perdendo tempo, e sim ganhando.

Então de cara, o que é indipensável é:

FUNCTION, LOCAL, PRIVATE

No final, o uso de classe é parecido com o uso disso.
Vai ser difícil aprender classe, se não aprendeu esses três.

Mas não quero aprender classe...
Ok, tudo bem, aprender isso não é pra usar classe, é pra aprender porque isso foi inventado há 25 anos atrás.
Falar sobre classe foi só um incentivo a mais: tudo tem a ver com a parte básica. ficar craque na parte básica é ficar craque em tudo que vém pela frente, porque na maioria das vezes, a novidade se trata de um "básico melhorado".

por **Pablo César** » 05 Fev 2017 20:32

Muito bom e legal a sua explicação Mr. Quintas.

Realmente tem muito programador que nem percebe nem liga a importância disto.

Eu gostei mas queria mais... acho que faltou explicar sobre variáveis STATIC e qual é a diferença com as do tipo LOCAL.
Se é possível é claro.

Aqui uma breve explicação do Wikipédia...

Um grande abraço

por **Claudio Soto** » 05 Fev 2017 22:10

Las variables locales se crean cada vez que se llama la rutina y se eliminan cuando esta retorna.

La variable estática se crea cuando se llama la rutina por primera vez y no se elimina cuando la funcion retorna, por lo tanto cada vez que se llama la rutina la variable estática conserva el valor que le asigno la última llamada a la funcion.

Otro tipo es la variable estática a nivel de archivo ya sea .prg o .c, en este caso la variable estática es visible (esta disponible) sólo dentro del fichero en la cual fue definida pero es visible (esta disponible) para todas las funciones de ese fichero. O sea actúa como local entre los diferentes archivos y como variable global dentro del archivo.

En resumen a nivel del lenguaje las variables estáticas se implementan como variables globales pero con acceso restringido sólo a la funcion (o al archivo) donde fue definida.

por **Pablo César** » 06 Fev 2017 06:24

Muchas gracias Claudio.

por **rubens** » 06 Fev 2017 07:34

Muito bom!!! Obrigadro Sr. Pablo e Sr. Claudio Soto ...

Mas se o Sr. José Quintas puder postar a explicação, apreciaria muito também... em português fica mais claro... dá para ter uma noção do que foi explicado pelo Sr. Claudio, mas em português com certeza, eu pelo menos fixaria melhor...

Obrigado,

Rubens

por **JoséQuintas** » 06 Fev 2017 09:07

Variáveis:

LOCAL

Só é visível na rotina, e é destruída no final.

PRIVATE

É visível na rotina atual, e em todas as rotinas chamadas a partir desta, mas por default, não em thread diferente
Era a única opção nas primeiras versões de Clipper, para isolar alguma coisa.

Um recurso pouco conhecido:

PROCEDURE Main
   PRIVATE A := 10
   ? A
   ? Rotina()
   ? A
   RETURN

FUNCTION Rotina()
   PRIVATE A := 2
   RETURN A

Isso vai mostrar 10, 2, 10
Apesar de nome repetido, vai ser criada uma variável private A somente pra rotina() que não tem nada a ver com a de Main.

PUBLIC

É visível no aplicativo inteiro, mas por default, não em thread diferente

STATIC

Depende de como foi declarada.
Se for declarada no início do fonte, ela vai ser visivel para todas as rotinas dentro do fonte, e o valor vai ser mantido.
Se for declarada dentro de uma função/rotina, só vai ser visível pela rotina
A diferença de LOCAL é que em STATIC o valor se mantém na próxima chamada.
Vale pra multithread.

FUNCTION Teste()
   STATIC A := 0 // na primeira chamada, A = 0
   A += 1  // cada vez que esta rotina for chamada, vai somar 1 em A
   RETURN A

THREAD STATIC

Mesmo anterior, mas cada thread tem sua própria variável STATIC

Variáveis por referência:

É uma forma de passar valores entre rotinas, onde é usada diretamente a variável passada como referência.
Se o valor dessa variável for alterado, vai ser alterado também na rotina que fez a chamada.

PROCEDURE Main
   LOCAL A := 10
   ? A
   ? Rotina( @a )
   ? A
   RETURN

FUNCTION Rotina( x )
   X := 20
   RETURN x

Isso vai mostrar 10, 20, 20

A variável A foi passada por referência.
Apesar de Rotina() usar com o nome X, o conteúdo de A vai ser alterado porque é por referência

Exemplos mais práticos:

Na HMG não se pode abrir a mesma janela mais de uma vez.
Uma alternativa seria usar a variável estática, e ter um nome diferente a cada chamada.

PROCEDURE CLIENTES
   STATIC nForm := 0
   LOCAL cForm
   nForm += 1
  cForm := "CLIENTES" + StrZero( nForm, 4 )
  DEFINE WINDOW &cForm ...

Que tal recalcular uma nota fiscal, usando a mesma rotina no aplicativo inteiro?
Só usar variáveis por referência, assim não prende a nome nenhum.

//Rotina 1:
Recalcula( @nQtProduto1, @nQtProduto2, @nQtTotal )

//Rotina 2:
Recalcula( @xxxQtProduto, @xxxQtProduto2, @xxxTotal )

//Rotina de cálculo:
FUNCTION Recalcula( nQt1, nQt2, nTotal )
...
RETURN NIL

Como não depende de nome de variável, cada rotina pode ser alterada à vontade.
Se usar variável PUBLIC ou PRIVATE, não vai poder alterar uma rotina sem alterar a outra.
E acabaria deixando todo o aplicativo preso a ter sempre os mesmos nomes, dificultando qualquer alteração.

por **JoséQuintas** » 06 Fev 2017 09:22

Um exemplo simples de STATIC.
Por exemplo, pra arquivo temporário.

Supondo que a cada chamada seu aplicativo pegue um número de um DBF ou base.
O aplicativo só precisaria adicionar um sequencial diferente a cada uso, e não teria nome repetido.

FUNCTION TempFile( cCarga )
 STATIC A := 0 
 A += 1 
   RETURN "TMP" + cCarga + StrZero( A, 10 ) + ".TMP"

por **asimoes** » 06 Fev 2017 18:49

Olá Quintas,

Você pode me ajudar nesta questão?

É possível fazer isso:

Adicionar o objeto da classe com as propriedades preenchidas, desculpa se estiver errado.

METHOD Cria() CLASS LstConexaoNg_Fct
     aLstConexao := {}
     // chamar WebService do GerAcesso para pegar as conexoes do sistema
     oConexaoAdoNg := ConexaoAdoNg():new()
     
     oConexaoAdoNg:Id    := "ORAPRIN"
     oConexaoAdoNg:Login := "A_000"
     oConexaoAdoNg:Senha := "A_000"
     
     aAdd(aLstConexao, oConexaoAdoNg) 
     
     oConexaoAdoNg:Id    := "ORAPRIN"
     oConexaoAdoNg:Login := "A_001"
     oConexaoAdoNg:Senha := "A_001"
     
     aAdd(aLstConexao, oConexaoAdoNg)
     
RETURN aLstConexao

por **JoséQuintas** » 06 Fev 2017 19:52

Estávamos falando de variáveis, mas ainda se encaixa no título do tópico
E de certa forma, tem a ver com uso de variáveis ou "alimentar" variáveis.

Achei que a pergunta e o fonte estão esquisitos parece que o fonte não se encaixa na pergunta.

Se está se referindo à variável/propriedade da classe:

CREATE CLASS Conexao
   VAR Servidor INIT "valor inicial"
   VAR Usuario INIT "alguem"
   VAR Senha INIT "sei la"

Isso vai criar a variável NOME onde o conteúdo inicial vai ser "valor inicial".

Ou.... o New() é um método/função da classe, só passar o conteúdo pelo New()

oConexao := Conexao():New( servidor, usuario, senha )

METHOD New( a, b, c ) CLASS Conexao
   IF a != NIL
      ::Servidor := a
   ENDIF
   IF b != NIL
      ::Usuario := b
    ENDIF
   IF c != NIL
      ::Senha := c
   ENDIF

Só que do jeito que está seu fonte, parece que vai ser uma conexão única.
Sem entender porque tantas conexões, mas aplicando o que mostrei aqui, seu fonte poderia ficar assim:

METHOD Cria() CLASS LstConexaoNg_Fct
   aLstConexao := {}
   AAdd( aLstConexao, ConexaoAdoNg():new( "ORAPRIN", "A_000", "A_000" ) )
   AAdd( aLstConexao, ConexaoAdoNg():New( "ORAPRINT", "A_001", "A_001" ) )
   AAdd( aLstConexao, ConexaoAdoNg():New( "ORAPRINT", "A_002", "A_002" ) )
  RETURN aLstConexao

É... tem a ver com o título do tópico... também é conhecimento indispensável tentar simplificar rotinas.... rs

por **Pablo César** » 06 Fev 2017 20:38

Sinceramente eu ainda não entendi 100%. Imagem

Vou assimilar-los amanhã, mas ainda acho dificil entender STATIC. Imagem

STATIC seria como o PRIVATE ma age como LOCAL ?
Acho que é isso... Imagem

Este exemplo do colega polonês Krzysztof, colocou recentemente este código com STATIC:

FUNCTION ChangeHeightRG()
STATIC lFixedH := .T.
LOCAL nHeight

lFixedH := ! lFixedH
nHeight := RadioGroup_Format("RadioRG", "MainWA", 7, lFixedH)

MainWA.RadioFR.HEIGHT := nHeight + 30
MainWA.HeightBU.ROW   := MainWA.RadioFR.HEIGHT + 25

MainWA.HEIGHT := (MainWA.HEIGHT - MainWA.CLIENTAREAHEIGHT) + MainWA.HeightBU.ROW + MainWA.HeightBU.HEIGHT + 10

MainWA.HeightBU.CAPTION := If(lFixedH, "&Set variable height", "&Set fixed height")
RETURN NIL

O engraçado que se substituir STATIC por LOCAL, não dá erro mas também não executa devidamente...
Esta parte de código é para deixar o RadioGroup em várias linhas cada item.

por **JoséQuintas** » 06 Fev 2017 21:45

Um teste simples é o que mostrei.

FUNCTION ProximoNumero()
   STATIC nNumero := 0
   nNumero += 1
   RETURN nNumero

Depois pode usar a vontade dentro do aplicativo.
Num simples:

PROCEDURE Main()
   ? ProximoNumero()
   ? ProximoNumero()
   ? ProximoNumero()
   ? ProximoNumero()
   ? ProximoNumero()
   RETURN

Isso vai mostrar:
1
2
3
4
5

Na função, o conteúde começou em zero, e foi somando um. Mas não foi zerado a cada chamada, a função "lembrou" do valor anterior.
Não é igual PUBLIC, porque SÓ A FUNÇÃO enxerga essa variável.

Quem está online