Creo, como tu, que la evolución es esta: Clipper fallaba porque su prepocesador acababa siendo incapaz de digerir tanta sintaxis, tanta descripción. Fivewin hizo lo que pudo para mantener esta forma de describir el código de que se disfraza el lenguaje Clipper, pero trabaja sobre el motor de objetos. Ya tenemos un "vicio", la sintaxis de Clipper, con una virtud, los objetos de fivewin.

Tabajando sobre un vicio, Fivewin llega a crear otro:
si alguien decide pasarde los comandos e ir directamente a las llamadas de clases se encuentra con el problema de que no todas las variables que deberían ser iniciadas por las llamadas clase:variable = valor, pueden serlo, que al tener que clases con mas de 10, 15, 20 variables en órdenes no siempre iguales) es muy poco gratificante... Con éllo, decidirse a trabajar bajo Fivewin con clases, llamando a clases y a métodos, con poquísimas funciones convencionales, acaba siendo algo parecido a la navegación por una costa llena de escollos: sólo vale la experiencia, nada la teoría.

Al orientarse plenamente a objetos, parece que Bruno no va a poder caer en el error de tener un GUI con declaraciones descohesionadas las unas con las otras. Además, visto el mercado, creo que es la mejor forma de acercarse a un IDE que realmente funcione, con garantías.

Nos queda pedirle a Bruno que el IDE genere código ya. Sólo así podríamos perdonar a C3 el no leer los recursos del RW de Borland, aunque habría que ver cómo se crearan aplicaciones multilenguaje de forma ágil.

Hola Jaime,

Todo es cuestión de gustos. Los comandos que usas en FiveWin se traducen a través del preprocesador para convertirse en el código de acceso a los objetos.

Tengo entendido que C3 tambien contará con comandos preprocesados alguna vez. Los comandos ayudan mucho cuando no se dispone de IDE y, como bien dice Miquel, hay que inicializar variables o ejecutar métodos y funciones justo después de la creación del objeto.

Personalmente me gusta más escribir el código usando POO directamente, pero hay muchas cosas que en FW o la haces con comandos o puedes despedirte que te funcionen a la primera.

Saludos,

Que mal lo mío! Recien ahora descubro esto, y llego tarde a los comentarios!
De todas maneras, me parece un tema excelente. Creo que hay algo que sería bueno tener en consideración: Los comandos permiten abstraerse de la implementación y no son, bajo ningun concepto, antónimos de POO (me viene a la mente eso de "con un martillo en la mano, todo tiene cara de clavo").
POO es algo fantástico y no amerita opinar ni extenderse. Pero las ventajas fundamentales están dadas por la manipulación que permite sobre modelos o patrones, permitiendo utilizarlos como una unidad.
Pero los comandos, por otro lado, permiten programar en forma imperativa, abstrayendonos de la complejidad de la implementación.
Clipper y FiveWin son una demostración perfecta de lo que quiero decir. Nunca hizo falta conocer en detalle las variables de instancia de un objeto GET, sin embargo lo hemos usado hasta el hartazgo. Y con FW, si bien tenemos disponible el codigo, lo he usado de manera intensiva solo con conocer los comandos.
En definitiva: ambas son herramientas complementarias y a mi parecer, imprescindibles.

Carlos

Estimados:

En Clipper se podía crear una variable, por ejemplo var1, con el siguiente valor: Var1="File" + "0001", y podia llamar a la variable como Var1 para cambiar su valor o bien como &Var1 que sería lo mismo que file0001 lo que me permitia hacer llamadas a archivos de sistema o bien crear variables dinamicas, ¿Es posible hacer esto con Visual Basic?