Cita:
Empezado por mamcx
Sinceramente no entiendo como dicen que Delphi es malo en cuanto a mantener la compatibilidad... si ese es precisamente uno de sus puntos fuertes.
Ademas, si incluso mantienen BDE hasta la version actual, y QuickReports lo incluyen.
Otro se queja de que hay muchos componentes "pa' lo mismo"... pues que eso sino soporte hacia atras? O mejor a lo MS... que quita del todo la posibilidad (como ej: ADO-ADO.NET).
Otro problema, y ese no lo arregla nadie, es programar sin pensar en el cambio:
http://dn.codegear.com/article/32388 |
Hola,
Es que se trata de conceptos diferentes.
Una cosa es que se pueda compilar un programa Delphi en una versiòn superior y otra cosa es que ese programa Delphi aproveche la versiòn superior (o sea, verdadera migraciòn).
Ciertamente, Delphi ha sido muy bueno en mantener compatibilidad; entendiendo por tal el poder compilar sin cambios, o con cambios mìnimos un programa de una versiòn anterior; pero al hacerlo, salvo una que otra excepciòn, simplemente estoy obteniendo el mismo programa que ya se tenìa, luego entonces, para que cambio de versiòn ?.
El problema, es que con el enfoque que ellos dieron, si se quiere justificar el cambio de versiòn toca re-codificar mucho. En el ejemplo que dì antes, lo lògico era que ellos re-escribieran el BDE para brindar las capacidades que incluyeron en dbExpress; asì el esfuerzo de cambio para el programador final serìa mìnimo.
En cuanto a lo que dices que me quejo de que hayas varias teconologìas de lo mismo y de que eso es soporte hacia atras, tienes razòn si lo miras desde la òptica de un Delphi 2007. Sin embargo, si lees con cuidado mi nota veràs que no era a eso a lo que me referìa. Lo que querìa decir es que nunca debieron haberse puesto a incluìr tantas variaciones de lo mismo; en su lugar, debieron mantener una sola base y simplemente mantenerse mejorandola; en otras palabras, lo que acabo de mencionar en el parrafo anterior. Màs claro aùn, estoy de acuerdo en que ahora toca mantenerlas todas, lo que estaba criticando es que considero una mala estrategia haberlas planteado porque al hacerlo se gastaron una cantidad de recursos que hubiera sido mucho mejor emplearlos en optimizar lo existente.
Sobre el problema de "programar sin pensar en el cambio" estoy totalmente de acuerdo, y soy de los defensores convencidos de la necesidad de programar para que las aplicaciones sean portables.
Por ejemplo, yo uso una metodologìa de portabilidad de Base de Datos, y en eso soy muy estricto, que me ha permitido cambiar de motor sin tener que cambiar programas, tan solo cambiando el Alias a nivel de BDE. Asì he pasado sin problemas, entre otros de Interbase a Oracle, y de Oracle a MS-SQL server. Otro ejemplo, tambièn uso otra metodologìa que me permite cambiar del modelo cliente servidor de dos capas convencional al modelo de conectividad Web, con un mìnimo de esfuerzo.