Olá, Fabiano.

>1) O OOP do VFP foi criado na versão 3.0 a muito tempo e já foi um trauma, já o .NET é novinho em folha então dá para colocar tudo quanto é "blablabla" de OOP nele.

Sim, sem dúvidas o .NET foi criado procurando corrigir problemas de implementações de diversas outras linguagens. No entanto, quando OOP foi introduzida no VFP 3, os conceitos de OOP já existiam há pelo menos uns 20 anos, então estou certo de que algumas outras coisas poderiam ter sido implementadas no VFP desde aquela época (mas também entendo que quanto mais coisa, mais traumatizante seria para migrarmos do xBase para uma linguagem OOP).


>2) Acho que o VFP esta apontando para uma migração "suave" ao colocar o AS "tipo", pois para melhorar o intelisense não é não :D Porque não adianta nada a gente colocar "as number" hoje... Mas amanhã acredito que só funcionará assim, então estamos tornando isso uma "boa prática de programação"

Um dos lemas da Microsoft quando lança uma nova versão do VFP é sempre dizer que a versão nova tem compatibilidade retroativa (ou seja, podemos recompilar aplicações na versão nova sem "quebras"). Eles vêm mantendo isso há anos e anos, e se realmente quiserem partir para uma "tipagem forte", quebrarão TODAS as aplicações existentes. Sinceramente, acho muito difícil de ver isto acontecendo.

A mesma coisa acontece com tratamento de erros: apesar de agora termos o Try/Catch, existe uma problema técnico (agora não me lembro de cabeça qual é...), que para corrigir, seria necessário alterar completamente a forma como o VFP vinha tratando erros (através de ON ERROR / Error event). Imagina a MS fazendo esta correção e quebrando o código de todo mundo... é complicado.


>3) O Código defensivo do VFP faz com que a gente tenha muuuuito mais flexibilidade, e não é só o xBase que pensa assim: PHP, Perl (se me lembro bem) e mumps pensam assim. Pois a falta de tipo "fixo" confere ao programador possibilidades inusitadas.

Sim, foi o que eu disse. O problema é que não precisamos desta flexibilidade 100% do tempo, e acabamos pagando um preço alto por isto.


>4) A Sobrecarga sempre foi interessante, mas o "contruction" (como é assa expressão em português?) sempre achei terrivel faltar no VFP.

"Constructor". :)


>5) Como fica a questão de macros nessa jogada toda? Porque o .Net nã aceita macros? Existe algum fundamento técnico (pois o código .Net não é nativo como o VFP) que proiba esta prática?

O .NET não aceita macros porque seria impossível o compilador detectar erros, e isso vai contra a idéia de "código gerenciado" da plataforma. Entretanto, através de um recurso chamado "Reflection", é possível escrever código que será "decidido" em tempo de execução, mas ainda tendo a possibilidade de ter o compilador supervisionando nosso código.


>A sua opnião, nos meros mortais, que desenvolvemos no VFP devemos esperar uma integração com o .NET ou mudar para .NET pois o VFP será sempre um produto "que tinha tudo para dar certo?". Pois estou estudando Java e não .NET pois se for para migrar, migro para Java embora seja um tremendo balaio de gato :)

Bom, eu não entendo nada de Java (o Fábio pode dar uma luz aqui) pois nunca nem vi a cara dele. Mas sempre vem sendo dito que a Microsoft construiu o .NET framework (e principalmente o C#), buscando não cair nos problemas que o Java enfrenta (ou seja, pegaram o que deu certo, e corrigiram ou excluiram aquilo que não deu certo).

A integração do VFP com .NET está vindo através de Web Services, novas classes (como a XMLAdapter, que aprimora a integração com ADO.NET), e também COM Interop (onde é possível utilizar componentes VFP no .NET e vice-versa). Não consigo visualizar mais do que isso.

O VFP ainda tem o seu lugar no mercado, mas temos que ficar atentos se nossa intenção é conseguir projetos e clientes maiores. Veja quantos importantes desenvolvedores em VFP estão trabalhando duro em direção ao .NET: Kevin McNish (Mere Mortals), Rick Strahl (west-wind), Markus Egger, só para listar alguns. Eu vejo assim: estes caras criaram coisas maravilhosas em VFP, e estão vendo um potencial imenso em .NET (após já terem roído bastante osso duro para entendê-lo)... então, penso que seja uma boa idéia para todos nós, no mínimo, dar uma olhada no .NET, para ver o que ele tem a oferecer, e onde se justifica, afinal, também não tenho dúvidas de que em diversos cenários, é o VFP que dita as regras. ;)