renato wulf jr | 1 Oct 02:06 2011
Picon

Re: Lazarus e Android

Podes postar o código fonte?

Renato

--
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR
Marcos Douglas | 1 Oct 22:12 2011
Picon

Re: [lazarus-br] Re: Revisão do Lazarus via diretiva

2011/9/30 silvioprog <silvioprog@...>:
> On 30 set, 17:54, silvioprog <silviop...@...> wrote:
>> Achei:
>>
>> C:\lazarus\examples\lclversion.
>
> Tem o recurso mas não funciona, olha a maravilha que recebi num teste
> simples que fiz aqui:
>
> "Error: Compile time expression: Wanted STRING but got BOOLEAN or
> INTEGER at "LCL_MAJOR = 0"".
>
> Para este teste:
>
> uses
>  LCLVersion,
> {$IF (LCL_MAJOR = 0) AND (LCL_MINOR = 9) AND (LCL_RELEASE <= 30)}
>  Classes,
> {$ENDIF}
>
> Parece que não tem como saber a versão da LCL na cláusula uses. Que
> pena.

No FPC eu já fiz algo assim:
{$IF (FPC_VERSION>=2) AND (FPC_RELEASE>4)}

Na LCL eu não tentei.

Marcos Douglas

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

Marcos Douglas | 2 Oct 16:44 2011
Picon

IUP para Pascal (era: Integrando pela linha de comando, programas escritos em diferentes linguagens)

Luciano,

Você tem algum projeto, com prazo, que gostaria de fazer em IUP com Pascal?
Gostaria de ajudá-lo na tradução de IUP para Pascal, porém estou meio
atarefado no momento. Não posso dedicar 100% do meu tempo livre neste
projeto.
Preciso saber se você está mesmo convencido de que utilizar IUP com
Pascal seria a melhor maneira de você criar suas interfaces gráficas.
Assim poderemos dar início a um projeto Open Source, no GoogleCode,
para que toda a comunidade Pascal venha se beneficiar de mais um
wrapper para Lua-IUP.

Marcos Douglas

2011/9/21 Marcos Douglas <md@...>
>
> Luciano,
>
> Respostas quotadas abaixo:
>
> > Então, acho que o meu inglês falhou porque, na verdade, não entendi
> > que alguém faria a tradução. E exatamente porque não entendi assim é
> > que preferi perguntar em um grupo de C, nacional, em que o C não se
> > tornaria ainda mais complicado por expressar-se na língua de Shakespeare.
>
> Na época tinha entendido que iriam fazer a conversão pra você e que
> isso não era tão difícil (tem muita gente que conhece bem C por lá).
>
> > Se falta apenas este header? Quem dera. Devo ter uns 3 ou 4 headers
> > convertidos. O que sucedeu é que, havendo perguntado na CPPBrasil, as
> > respostas que obtive induziram-me a crer que eu tentava algo muito
> > difícil de ser conseguido com o meu nível de conhecimento. E então,
> > porque havia outras opções: como trabalhar somente com Lua ou com
> > FPWeb, realmente desisti antes de ter completado a tentativa.
> > Sugeriram-me que expandisse os símbolos da macros com o GCC. Deram-me
> > uma linha de comando, tentei-a e não consegui. A ajuda foi frontal e
> > ainda assim, não consegui. Recuperarei esta mensagem para ver se
> > consigo algo diferente.
>
> Sobre o GCC ou qq coisa relacionada ao C especificamente eu não posso
> comentar, pois não é minha especialidade. Porém ainda continuo achando
> que o caminho fácil é a tradução dos headers.
>
> > Se contatei o desenvolvedor de IUP? Sim, ele foi muito gentil. É que
> > não sei exatamente o que lhe perguntar, mas em tudo quanto seja
> > possível, de certo, ajudará. Informou-me que não há planos de que o
> > laboratório se dedique a um binding para Lua, mas que ficaria
> > francamente feliz se este fosse desenvolvido.
>
> O bind no qual vocês se referiram era especificamente Pascal ou ele
> quis dizer qualquer outro bind (que não exista ainda)?
> Poderia enviar, em particular, o contato específico do criador do IUP?
>
> > A encruzilhada em que me encontro é a seguinte: “Não consegui
> > traduzir”. “então, compreenda como funciona a biblioteca”. “Mas para
> > isso terei de aprender C”. “Ora, então, aprenda C”. “Aprender C apenas
> > para converter tudo para Pascal?”
>
> Não digo que seria uma perda de tempo aprender outra linguagem (ainda
> mais sendo C) mas seria um desperdício de tempo já que você não quer
> trabalhar com esta linguagem. Mas considere aprender o básico...
> coisas específicas que possam lhe ajudar na tradução.
>
> > Em suma, de fato, quero efetuar a tradução, mas não quero tanto que me
> > dispusesse a aprender C apenas por este motivo.
>
> Estou pensando (novamente) eu lhe ajudar com esta tradução. Porém não
> vejo C a muito tempo. Pra que eu consiga fazer isso eu teria que tirar
> o pó de alguns livros e relê-los novamente.
>
> > Recuperarei a mensagem, encaminharei um pedido de ajuda ao FPC-devel
> > especificamente para este header e, então, vejamos em que resulta.
>
> Somente uma correção: envie a lista fpc-pascal pois a fpc-devel é
> apenas relacionada ao compilador.
>
> > Em tudo o que dissemos, Marcos, o que mais me surpreendeu foi o fato
> > de ter avaliado como mais simples a tradução dos headers do que a
> > integração pela linha de comando. Não tinha idéia de que esta poderia
> > ser tão complicada.
>
> A tradução, pra quem conhece C e Pascal, é relativamente simples -
> mesmo sem ver os headers eu posso afirmar isso - mas programar
> utilizando integração via linha de comando é muito propenso a erros e
> uma tarefa mais árdua. Sem falar que, fazendo a tradução, você (nós)
> estaríamos ajudando a comunidade Pascal e/ou Lua/IUP por
> disponibilizar mais um bind pra uso geral.
>
> Marcos Douglas

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

Luciano de Souza | 2 Oct 16:52 2011
Picon

[lazarus-br] Adição, exclusão e pesquisa em bancos DBF

Caros,

O Sqlite é magnífico, mas o DBF, por não lidar com SQL, também parece 
apresentar as suas facilidades. NO entanto, não consegui encontrar bons 
exemplos sobre DBF. Nada tenho contra o SQL. A bem dizer, gosto. Mas 
para coisas realmente muito simples como uma tabela, um conjunto de 
registros, adição, exclusão e pesquisa, em tão pequeno escopo, o DBF 
parece promissor.

A wiki do Lazarus, ensina a criar tabelas e índices, mas como se 
adicionam e excluem registros? Como se efetua uma pesquisa?

Isto é perfeitamente lógico e funciona, mas não encontro material que 
permita ir um pouco mais longe.

program e003;
{$mode objfpc}{$h+}

uses
db, dbf, dbf_common;

var
base: tdbf;

begin
base := tdbf.create(nil);
base.filepath := 'data';
base.tablelevel := 7;
base.tablename := 'e003.dbf';
base.exclusive := true;
with base.fielddefs do
begin
add('id', ftAutoinc, 0, true);
add('name', ftString, 80, true);
end;
base.createtable;
base.free;
end.

Já que voltei para o Pascal, estou a retirar dos porões, os códigos com 
os quais já brinquei em algum momento.

Luciano

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

Prisma - GMAIL | 2 Oct 17:28 2011
Picon

Re: [lazarus-br] Adição, exclusão e pesquisa em bancos DBF

Acredito que isto deva te ajudar:

- Deletar:

Tabela.Delete;

- Inserir novos registros:

Insere registro na posição do cursor
Tabela.Insert;

Adiciona no final da Tabela
Tabela.Append;

Para Gravar :

Tabela.Post;

Para Editar:

Tabela.Edit;

Sucesso !

Moacir

Em 02/10/2011 11:52, Luciano de Souza escreveu:
> Caros,
>
> O Sqlite é magnífico, mas o DBF, por não lidar com SQL, também parece 
> apresentar as suas facilidades. NO entanto, não consegui encontrar 
> bons exemplos sobre DBF. Nada tenho contra o SQL. A bem dizer, gosto. 
> Mas para coisas realmente muito simples como uma tabela, um conjunto 
> de registros, adição, exclusão e pesquisa, em tão pequeno escopo, o 
> DBF parece promissor.
>
> A wiki do Lazarus, ensina a criar tabelas e índices, mas como se 
> adicionam e excluem registros? Como se efetua uma pesquisa?
>
> Isto é perfeitamente lógico e funciona, mas não encontro material que 
> permita ir um pouco mais longe.
>
> program e003;
> {$mode objfpc}{$h+}
>
> uses
> db, dbf, dbf_common;
>
> var
> base: tdbf;
>
> begin
> base := tdbf.create(nil);
> base.filepath := 'data';
> base.tablelevel := 7;
> base.tablename := 'e003.dbf';
> base.exclusive := true;
> with base.fielddefs do
> begin
> add('id', ftAutoinc, 0, true);
> add('name', ftString, 80, true);
> end;
> base.createtable;
> base.free;
> end.
>
> Já que voltei para o Pascal, estou a retirar dos porões, os códigos 
> com os quais já brinquei em algum momento.
>
> Luciano
>

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

Picon

Re: [lazarus-br] Adição, exclusão e pesquisa em bancos DBF



Em 2 de outubro de 2011 11:52, Luciano de Souza <luchyanus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> escreveu:
Caros,

O Sqlite é magnífico, mas o DBF, por não lidar com SQL, também parece apresentar as suas facilidades. NO entanto, não consegui encontrar bons exemplos sobre DBF. Nada tenho contra o SQL. A bem dizer, gosto. Mas para coisas realmente muito simples como uma tabela, um conjunto de registros, adição, exclusão e pesquisa, em tão pequeno escopo, o DBF parece promissor.


Com o componente TSqlite3Dataset é possível usar o sqlite sem usar SQL.

Veja os tutoriais em http://sqlite4fpc.yolasite.com/documentation.php

Nele aprende-se a adicionar / remover sem usar sql.

É possível procurar com o Locate / LocateNext / Lookup

Atualmente não é possível filtrar os dados sem sql mas pretendo adicionar em um futuro próximo

Isso com as vantagens de ser um formato mais robusto e sem algumas limitações como o tamanho do nome dos campos em comparação com o dbf

Luiz
 
A wiki do Lazarus, ensina a criar tabelas e índices, mas como se adicionam e excluem registros? Como se efetua uma pesquisa?

Isto é perfeitamente lógico e funciona, mas não encontro material que permita ir um pouco mais longe.

program e003;
{$mode objfpc}{$h+}

uses
db, dbf, dbf_common;

var
base: tdbf;

begin
base := tdbf.create(nil);
base.filepath := 'data';
base.tablelevel := 7;
base.tablename := 'e003.dbf';
base.exclusive := true;
with base.fielddefs do
begin
add('id', ftAutoinc, 0, true);
add('name', ftString, 80, true);
end;
base.createtable;
base.free;
end.

Já que voltei para o Pascal, estou a retirar dos porões, os códigos com os quais já brinquei em algum momento.

Luciano

--
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br <at> googlegroups.com
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe <at> googlegroups.com
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

--
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR
luciano de souza | 3 Oct 14:49 2011
Picon

Os paradigmas linear, estruturado e orientado a objetos

Caros,

Com o Object Pascal, pode-se programar segundo 3 paradigmas: linear,
estruturado ou orientado a objetos. Sei que existe ainda o paradigma
funcional e o orientado a aspectos, mas não os conheço, não sei se o
Lazarus os suporta e, muito menos, quais são suas vantagens e
desvantagens. De qualquer modo, os meus parcos conhecimentos, até o
momento, tem indicado que a escolha entre um paradigma e outro
depende:

1. Da linguagem - o Assembly não suporta outro paradigma senão o
linear, então, se a escolha é Assembly, o paradigma é linear ao menos
no que diz respeito ao código. Durante algum tempinho, utilizei uma
linguagem de programação chamada Scripvox, concebida para estimular
pessoas cegas a criar programas simples no ambiente Dosvox. Mesmo não
havendo suporte a funções, cada label era para mim uma função e, mesmo
apenas com variáveis globais, era possível pensar em termos de
funções, com seus argumentos e retornos.

2. Do desempenho - Parece-me que a programação estruturada oferece
mais desempenho do que a orientada a objetos. Já ouvi este comentário
e, mesmo não entendendo bem do assunto, parece-me razoável. Um objeto
é um pacote de dados e funções. Se utilizarei apenas alguns dados e
algumas funções, então, a sua instanciação implica desperdício de
memória. E não será verdade que ou objeto do tipo tSqlite3Dataset
possui muitos dados e muitas funções? Não haverá ganho no
gerenciamento da memória disponível se, ao invés disso, adotássemos
uma API não orientada a objetos?

3. Da manutenção - Em dado momento, parece ter havido um concenso de que:
a) Sob o paradigma estruturado, a manutenção é mais difícil, portanto,
produzem-se sistemas mais inflexíveis, gerando altos custos de
manutenção e pouca flexibilidade para mantê-lo convergente às
necessidades dos usuários.
b) O hardware evoluiu a um ponto que, na maioria das vezes, a perda de
desempenho, gerada pela POO, é compensada pelos métodos que oferece à
modelagem, codificação e mantenibilidade.
c) Consideram-se características relevantes: a abstração (a capacidade
de modelar o mundo real), o encapsulamento (a caixa preta), a herança
(que propicia reaproveitamento de código) e o polimorfismo (a
capacidade de uma funcionalidade ter significados diferentes para
classes diferentes).

O que me fez pensar em tudo isso, foram alguns artigos sobre o
paradigma estruturado, remetidos pelo Marcos Douglas. ainda não me
aprofundei em seus conceitos. De qualquer modo, sei que as verdades na
informática dependem de serem contextualizadas. Não tenho experiência
para que possa ter uma opinião definitiva sobre o assunto, mas as
minhas impressões são:
a) O paradigma estruturado parece mais simples, mas não tão
organizado. Ao menos de início, parece não impor tanto rigor na
modelagem, por isso mesmo, iniciar parece mais fácil do que continuar.
b) O paradigma orientado a objetos, por vezes, parece querer encontrar
relações entre dados e funções onde não existe ou não é natural.

Durante algum tempo, fiquei a imaginar que, como não possuo uma
metodologia, a POO seria melhor porque, restringindo-me a certos
grilhões conceituais, obrigava-me a pensar melhor no projeto.

De qualquer modo, é preciso destacar que, seja sob um ou outro
paradigma, há boas e más práticas. Então, gostaria de ouvir a
experiência dos colegas. Em que medida as anotações que aqui fiz são
pertinentes?

Luciano

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

luciano de souza | 3 Oct 15:03 2011
Picon

Re: [lazarus-br] Adição, exclusão e pesquisa em bancos DBF

Muito bom. A API do Sqlite sem SQL é realmente simples. E o
extraordinário é que, embora um tanto óbvio, somente agora percebi a
importância de estudar o tDataset, pois quase todos os métodos de
tSqlite3Dataset, dele descendem.

A sintaxe para tDBF e tSqlite3Dataset são muito similares. Parece que
não apenas o último, mas também o primeiro, descende de tDataset.

Faltava-me coisas como:
ds.FieldbyName('name').asstring para carregar o dataset e ds.clear,
ds.applyupdates.

Luiz, não conheço bem os projetos que cada um mantém por aqui. Sei que
o Sílvio mantém o LazSolutions a que eu tive o prazer de conhecer. Não
sabia que era o mantenedor do componente de Sqlite3 para Pascal.
Realmente, os meus parabéns. Pelo que vi, o seu trabalho é exuberante.

Em 02/10/11, Luiz Americo Pereira Camara<luizamericop@...> escreveu:
> Em 2 de outubro de 2011 11:52, Luciano de Souza
> <luchyanus@...>escreveu:
>
>> Caros,
>>
>> O Sqlite é magnífico, mas o DBF, por não lidar com SQL, também parece
>> apresentar as suas facilidades. NO entanto, não consegui encontrar bons
>> exemplos sobre DBF. Nada tenho contra o SQL. A bem dizer, gosto. Mas para
>> coisas realmente muito simples como uma tabela, um conjunto de registros,
>> adição, exclusão e pesquisa, em tão pequeno escopo, o DBF parece
>> promissor.
>>
>>
> Com o componente TSqlite3Dataset é possível usar o sqlite sem usar SQL.
>
> Veja os tutoriais em http://sqlite4fpc.yolasite.com/documentation.php
>
> Nele aprende-se a adicionar / remover sem usar sql.
>
> É possível procurar com o Locate / LocateNext / Lookup
>
> Atualmente não é possível filtrar os dados sem sql mas pretendo adicionar em
> um futuro próximo
>
> Isso com as vantagens de ser um formato mais robusto e sem algumas
> limitações como o tamanho do nome dos campos em comparação com o dbf
>
> Luiz
>
>
>> A wiki do Lazarus, ensina a criar tabelas e índices, mas como se adicionam
>> e excluem registros? Como se efetua uma pesquisa?
>>
>> Isto é perfeitamente lógico e funciona, mas não encontro material que
>> permita ir um pouco mais longe.
>>
>> program e003;
>> {$mode objfpc}{$h+}
>>
>> uses
>> db, dbf, dbf_common;
>>
>> var
>> base: tdbf;
>>
>> begin
>> base := tdbf.create(nil);
>> base.filepath := 'data';
>> base.tablelevel := 7;
>> base.tablename := 'e003.dbf';
>> base.exclusive := true;
>> with base.fielddefs do
>> begin
>> add('id', ftAutoinc, 0, true);
>> add('name', ftString, 80, true);
>> end;
>> base.createtable;
>> base.free;
>> end.
>>
>> Já que voltei para o Pascal, estou a retirar dos porões, os códigos com os
>> quais já brinquei em algum momento.
>>
>> Luciano
>>
>> --
>> Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
>> nos Grupos do Google.
>> Para postar neste grupo, envie um e-mail para
>> lazarus-br@...
>> Para cancelar a sua inscrição neste grupo, envie um e-mail para
>> lazarus-br+unsubscribe <at> **googlegroups.com<lazarus-br%2Bunsubscribe <at> googlegroups.com>
>> Para ver mais opções, visite este grupo em
>> http://groups.google.com.br/**group/lazarus-br?hl=pt-BR<http://groups.google.com.br/group/lazarus-br?hl=pt-BR>
>
> --
> Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
> nos Grupos do Google.
> Para postar neste grupo, envie um e-mail para
> lazarus-br@...
> Para cancelar a sua inscrição neste grupo, envie um e-mail para
> lazarus-br+unsubscribe@...
> Para ver mais opções, visite este grupo em
> http://groups.google.com.br/group/lazarus-br?hl=pt-BR

-- 
Luciano de Souza

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

Marcos Douglas | 3 Oct 15:31 2011
Picon

Re: Os paradigmas linear, estruturado e orientado a objetos

Luciano,

Respostas abaixo:

> 1. Da linguagem - o Assembly não suporta outro paradigma senão o
> linear, então, se a escolha é Assembly, o paradigma é linear ao menos
> no que diz respeito ao código. Durante algum tempinho, utilizei uma
> linguagem de programação chamada Scripvox, concebida para estimular
> pessoas cegas a criar programas simples no ambiente Dosvox. Mesmo não
> havendo suporte a funções, cada label era para mim uma função e, mesmo
> apenas com variáveis globais, era possível pensar em termos de
> funções, com seus argumentos e retornos.

Felizmente o Pascal dá suporte ao modelo Procedural ou OO (mas contém
falhas ou limitações).

> 2. Do desempenho - Parece-me que a programação estruturada oferece
> mais desempenho do que a orientada a objetos. Já ouvi este comentário
> e, mesmo não entendendo bem do assunto, parece-me razoável. Um objeto
> é um pacote de dados e funções. Se utilizarei apenas alguns dados e
> algumas funções, então, a sua instanciação implica desperdício de
> memória. E não será verdade que ou objeto do tipo tSqlite3Dataset
> possui muitos dados e muitas funções? Não haverá ganho no
> gerenciamento da memória disponível se, ao invés disso, adotássemos
> uma API não orientada a objetos?

Está correto.
Uma API procedural seria muito mais "leve" e, dependendo, mais fácil
de utilizar.

> 3. Da manutenção - Em dado momento, parece ter havido um concenso de que:
> a) Sob o paradigma estruturado, a manutenção é mais difícil, portanto,
> produzem-se sistemas mais inflexíveis, gerando altos custos de
> manutenção e pouca flexibilidade para mantê-lo convergente às
> necessidades dos usuários.

Não concordo.
Na manutenção ambas as abordagens possuem vantagens e desvantagens;
isso vai depender do tipo de manutenção, veja
http://geocities.com/tablizer/shapes.htm
Um bom programador consegue fazer um bom sistema (flexível,
organizado, etc) em qq linguagem e/ou filosofia de desenvolvimento.

> b) O hardware evoluiu a um ponto que, na maioria das vezes, a perda de
> desempenho, gerada pela POO, é compensada pelos métodos que oferece à
> modelagem, codificação e mantenibilidade.

Correto. O overhead que a POO traz pode ser compensada pelo
hardware... mas isso depende da aplicação, por exemplo, dispositivos
móveis não podem se dar o luxo de ter um programa com centenas de
classes e instâncias.

> c) Consideram-se características relevantes: a abstração (a capacidade
> de modelar o mundo real), o encapsulamento (a caixa preta), a herança
> (que propicia reaproveitamento de código) e o polimorfismo (a
> capacidade de uma funcionalidade ter significados diferentes para
> classes diferentes).

Errado. Com exceção da herança, abstração, encapsulamento e
polimorfismo não são propriedades somente da POO, veja
http://geocities.com/tablizer/shapes.htm

> O que me fez pensar em tudo isso, foram alguns artigos sobre o
> paradigma estruturado, remetidos pelo Marcos Douglas. ainda não me
> aprofundei em seus conceitos. De qualquer modo, sei que as verdades na
> informática dependem de serem contextualizadas. Não tenho experiência
> para que possa ter uma opinião definitiva sobre o assunto, mas as
> minhas impressões são:
> a) O paradigma estruturado parece mais simples, mas não tão
> organizado. Ao menos de início, parece não impor tanto rigor na
> modelagem, por isso mesmo, iniciar parece mais fácil do que continuar.

A organização depende do programador.
Claro que a linguagem pode facilitar a criação de módulos reais, já
outras não (ex: C). Mas isso não impede a organização. Veja
http://z505.com/powtils/mop.shtml

> b) O paradigma orientado a objetos, por vezes, parece querer encontrar
> relações entre dados e funções onde não existe ou não é natural.

Exatamente, esta relação não existe no mundo real. Veja:
http://geocities.com/tablizer/abstract.htm
http://geocities.com/tablizer/whypr.htm

> Durante algum tempo, fiquei a imaginar que, como não possuo uma
> metodologia, a POO seria melhor porque, restringindo-me a certos
> grilhões conceituais, obrigava-me a pensar melhor no projeto.

Correto. Porque POO tem uma metodologia bem declarada, vários
conceitos, vários exemplos de padrões e, não menos importante, pq a
moda atual é POO, então fica mais fácil fazer programas assim pois
você irá encontrar mais gente que se interessa por esta abordagem.

> De qualquer modo, é preciso destacar que, seja sob um ou outro
> paradigma, há boas e más práticas. Então, gostaria de ouvir a
> experiência dos colegas. Em que medida as anotações que aqui fiz são
> pertinentes?

Deixo aqui alguns links:
http://geocities.com/tablizer/whypr.htm
http://geocities.com/tablizer/core1.htm
http://c2.com/cgi/wiki?DatabaseNotMoreGlobalThanClasses

Gostaria de deixar claro que conheço tanto POO como Procedural e vejo
vantagens e desvantagens em ambas. Porém, ao meu ver, são abordagens
completamente diferentes e, por isso, não podem ser comparadas.

Marcos Douglas

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR

luciano de souza | 3 Oct 15:37 2011
Picon

Re: IUP para Pascal (era: Integrando pela linha de comando, programas escritos em diferentes linguagens)

Marcos,

Se estou convencido? O Carlos Araújo mostrou-me as alternativas de que
disponho, utilizando a LCL. Confesso que fiquei bastante surpreendido.
A bem dizer, parece mesmo possível realizar o que desejo com a LCL.
Mas é claro. Conheço razoavelmente bem IUP e conheço muito pouco da
LCL. Uma comparação necessita de mais experiências.

Até o momento, parece-me que:
1. A LCL tem a formidável vantagem de não implicar a tradução de
bibliotecas do C;
2. IUP parece ser bastante mais simples no momento de criar os
componentes, isto porque trabalha com LED, uma linguagem de templates,
uma espécie de HTML ultrassimples que é ligado ao código Pascal.
3. A LCL é mais vantajosa quando se alteram atributos de objetos já criados;
4. Para IUP, já conheço solução para o problema de labels colocados ao
lado de edits, não serem lidos pelo leitor de telas, como sendo label
do edit respectivo.

Com a tradução de IUP ficarei congelado na versão 3.5. Exceto do que
diz respeito a correção de bugs, isto não é um problema, pois o que
oferece é bem mais do que necessito, pois pode bem imaginar que a
necessidade dos cegos no que tange a interfaces gráficas não é algo
muito exigente. É preciso sim que componentes estejam razoavelmente
alinhados. Imagine se um label ficar completamente distanciado de seu
edit. Muito provavelmente o leitor de telas não o reconhecerá como
tal. Isto é especialmente importante no Windows, pois a descoberta que
mencionei no item 4 não vale para Windows. O leitor de telas que
utilizo no Windows, realmente faz contas para identificar a posição e
inferir relações. No Linux, a uma função do GTK, biblioteca abstraída
por IUP, que estabelece esta relação programaticamente.

Em suma, no ponto em que estou, fazer uma opção não é o melhor
caminho. Gostaria de examinar as duas soluções. A LCL já está pronta,
então, é mais fácil de trabalhar sobre ela. Mas é claro, considerando
o que sei de IUP e, por isso mesmo, sendo este caminho fartamente
explorado, neste momento, ainda me pareceria opção melhor se houvesse
uma tradução para Pascal.

O problema é que não conheço C, então, esta é tarefa um bocado árdua
para mim. Neste caso, as minhas alternativas são:
1. Exploro a boa vontade do Marcos Douglas. A minha consciência diz
que talvez não seja uma associação que lhe seja lá muito favorável no
sentido em que o conhecimento, entre nós, está dividido de modo muito
pouco isonômico. Creio que tenho de estudar C para que me torne apto a
ser ajudado.
2. Apelo para os lazaristas pecadores que, buscando fugir do
julgamento final, querem reduzir os seus débitos com o mundo
investindo em uma causa social. Se aceitarem o convite, prometo
solenemente escrever 50 artigos sobre o Freepascal!

Enfim, se me pergunta qual caminho seguirei? A despeito de significar
duplo investimento de tempo, porque quero muito realizar este projeto,
por hora, seguirei os dois caminhos, pois ambos, sob suas perspectivas
parecem promissores.

Luciano

Em 02/10/11, Marcos Douglas<md@...> escreveu:
> Luciano,
>
> Você tem algum projeto, com prazo, que gostaria de fazer em IUP com Pascal?
> Gostaria de ajudá-lo na tradução de IUP para Pascal, porém estou meio
> atarefado no momento. Não posso dedicar 100% do meu tempo livre neste
> projeto.
> Preciso saber se você está mesmo convencido de que utilizar IUP com
> Pascal seria a melhor maneira de você criar suas interfaces gráficas.
> Assim poderemos dar início a um projeto Open Source, no GoogleCode,
> para que toda a comunidade Pascal venha se beneficiar de mais um
> wrapper para Lua-IUP.
>
> Marcos Douglas
>
>
> 2011/9/21 Marcos Douglas <md@...>
>>
>> Luciano,
>>
>> Respostas quotadas abaixo:
>>
>> > Então, acho que o meu inglês falhou porque, na verdade, não entendi
>> > que alguém faria a tradução. E exatamente porque não entendi assim é
>> > que preferi perguntar em um grupo de C, nacional, em que o C não se
>> > tornaria ainda mais complicado por expressar-se na língua de
>> > Shakespeare.
>>
>> Na época tinha entendido que iriam fazer a conversão pra você e que
>> isso não era tão difícil (tem muita gente que conhece bem C por lá).
>>
>> > Se falta apenas este header? Quem dera. Devo ter uns 3 ou 4 headers
>> > convertidos. O que sucedeu é que, havendo perguntado na CPPBrasil, as
>> > respostas que obtive induziram-me a crer que eu tentava algo muito
>> > difícil de ser conseguido com o meu nível de conhecimento. E então,
>> > porque havia outras opções: como trabalhar somente com Lua ou com
>> > FPWeb, realmente desisti antes de ter completado a tentativa.
>> > Sugeriram-me que expandisse os símbolos da macros com o GCC. Deram-me
>> > uma linha de comando, tentei-a e não consegui. A ajuda foi frontal e
>> > ainda assim, não consegui. Recuperarei esta mensagem para ver se
>> > consigo algo diferente.
>>
>> Sobre o GCC ou qq coisa relacionada ao C especificamente eu não posso
>> comentar, pois não é minha especialidade. Porém ainda continuo achando
>> que o caminho fácil é a tradução dos headers.
>>
>> > Se contatei o desenvolvedor de IUP? Sim, ele foi muito gentil. É que
>> > não sei exatamente o que lhe perguntar, mas em tudo quanto seja
>> > possível, de certo, ajudará. Informou-me que não há planos de que o
>> > laboratório se dedique a um binding para Lua, mas que ficaria
>> > francamente feliz se este fosse desenvolvido.
>>
>> O bind no qual vocês se referiram era especificamente Pascal ou ele
>> quis dizer qualquer outro bind (que não exista ainda)?
>> Poderia enviar, em particular, o contato específico do criador do IUP?
>>
>> > A encruzilhada em que me encontro é a seguinte: “Não consegui
>> > traduzir”. “então, compreenda como funciona a biblioteca”. “Mas para
>> > isso terei de aprender C”. “Ora, então, aprenda C”. “Aprender C apenas
>> > para converter tudo para Pascal?”
>>
>> Não digo que seria uma perda de tempo aprender outra linguagem (ainda
>> mais sendo C) mas seria um desperdício de tempo já que você não quer
>> trabalhar com esta linguagem. Mas considere aprender o básico...
>> coisas específicas que possam lhe ajudar na tradução.
>>
>> > Em suma, de fato, quero efetuar a tradução, mas não quero tanto que me
>> > dispusesse a aprender C apenas por este motivo.
>>
>> Estou pensando (novamente) eu lhe ajudar com esta tradução. Porém não
>> vejo C a muito tempo. Pra que eu consiga fazer isso eu teria que tirar
>> o pó de alguns livros e relê-los novamente.
>>
>> > Recuperarei a mensagem, encaminharei um pedido de ajuda ao FPC-devel
>> > especificamente para este header e, então, vejamos em que resulta.
>>
>> Somente uma correção: envie a lista fpc-pascal pois a fpc-devel é
>> apenas relacionada ao compilador.
>>
>> > Em tudo o que dissemos, Marcos, o que mais me surpreendeu foi o fato
>> > de ter avaliado como mais simples a tradução dos headers do que a
>> > integração pela linha de comando. Não tinha idéia de que esta poderia
>> > ser tão complicada.
>>
>> A tradução, pra quem conhece C e Pascal, é relativamente simples -
>> mesmo sem ver os headers eu posso afirmar isso - mas programar
>> utilizando integração via linha de comando é muito propenso a erros e
>> uma tarefa mais árdua. Sem falar que, fazendo a tradução, você (nós)
>> estaríamos ajudando a comunidade Pascal e/ou Lua/IUP por
>> disponibilizar mais um bind pra uso geral.
>>
>> Marcos Douglas
>
> --
> Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
> nos Grupos do Google.
> Para postar neste grupo, envie um e-mail para
> lazarus-br@...
> Para cancelar a sua inscrição neste grupo, envie um e-mail para
> lazarus-br+unsubscribe@...
> Para ver mais opções, visite este grupo em
> http://groups.google.com.br/group/lazarus-br?hl=pt-BR

-- 
Luciano de Souza

--

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "Lazarus-BR"
nos Grupos do Google.
Para postar neste grupo, envie um e-mail para
lazarus-br@...
Para cancelar a sua inscrição neste grupo, envie um e-mail para
lazarus-br+unsubscribe@...
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/lazarus-br?hl=pt-BR


Gmane