[quote name="Marc" post="42433" timestamp="1288292220"]
Parece que nos van quedando menos puntos de fricción
.[/quote]
Yo no estaría tan seguro
¡que soy de cabeza bien cuadrada! 
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Evidentemente este cambio no se haría para ahorrarse unos kbs en el .dfm, es para simplificar y tener más coherencia en el entorno. Personalmente preferiría poder ver la inicialización del formulario en el mismo código Pascal en el que se escribe el resto del programa.
[/quote]
No me convence que eso sería coherente con el entorno. ¿Mejor lo dejamos como que esta característica sea opcional y configurable por el programador? Podríamos seguir y seguir con este punto... yo no voy a aflojar.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Por cierto, ¿ porqué dices que con muchos Forms sería confuso ?. Si heredo un Form en otros Forms hijos, se ejecutaría el OnCreate del padre y el OnCreate de los hijos, haciendo la correspondiente inicialización en cada caso, que es lo que se quiere. No me parece confuso.
[/quote]
Si bien apoyo la idea de que en lo posible hay que aplicar la herencia visual, no siempre es posible. Yo hablé en términos generales... tanto como se si deba heredar como crear tanta ventanas de una misma clase pero tienen algunas cosas diferentes de una a otra.
A mi me resultaría confuso.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Bueno, a mi utilizar esos nombres me parece muy intuitivo, pero si lo encontráis problemático se pueden cambiar por cualquier otro para que no coinciden con las palabras usadas en la declaración de clases.
[/quote]
Como he dicho, es un mal menor. Si se modifica al compilador para entender apropiadamente el contexto en donde se declara las clásulas public/private se puede emplear para ambas (y otras) cosas.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Respecto a donde ubicaría las clases, pues la inmensa mayoría deberían ir en la parte public, pero por simetría también podrías declarar clases en la sección private de la Unit, cuando tengas la necesidad especial de que solo sea accesible en ese módulo.
[/quote]
¿Y allí mismo la pondrías todo junto... declaración y código de sus métodos? Entonces yo entiendo que tu idea sería hacer a las secciones public y private opcionales, como lo son initialization y finalization.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Ya estaba escribiendo que te equivocas, cuando me he fijado que estaba escribiendo mal tu prueba
. No me había fijado que lo habías colgado debajo de implementation (supongo que cuando lo miraba, ni siquiera leía esa primera línea, daba por asumido que era la línea Unit).Tienes razón, hay clases privadas (nunca se me había ocurrido declarar una clase en la sección de implementación).
[/quote]
¿Viste?
Pues si... una gran mayoría de las clases se diseñan para ser públicas, pero nada impide, si el diseño lo amerita, que existan clases privadas. [quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Aunque creo que este argumento ya no deberíamos tenerlo más en cuenta, puesto que hemos visto que es sencillo de solventar en una sintaxis unificada alternativa.
[/quote]
Aquí me pierdo
¿A cuál argumento te refieres? ¿Que no deberíamos tener en cuenta? ¿Lo de clase privada y públicas? Ten presente que estamos tratando en 3 temas centrales, que están medianamente relacionados:1. El tema de uso de .dfm vs concentrarlo todo en un Create
2. Separación Interface/Implementation vs Compactar y unificar: Código en la definición
3. Clases públicas y privadas: ¿Existen las privadas?
No comprendo a cual de esos temas te refieres.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Ahora entiendo por donde vas, y no, nunca he programado patrones (en mis tiempos la programación orientada a objetos aún no estaba en los planes de estudio).
[/quote]
Pues cuando cursé la cátedra de Lenguajes III y Lenguajes IV y ví la teoría de OO no tenía en el programa el tema de patrones. Incluso en cátedra de Ingeniería de Software cuando estudié UML tampoco tenía patrones en el programa.
Lo estudié por mi cuenta, como la gran mayoría de las cosas que he aprendido.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
En definitiva estamos hablando de lo mismo que en el párrafo anterior.
[/quote]
Mitá y mitá diría yo
Nos estamos confundiendo porque estamos apuntando a e temas un tanto relacionados... por ello yo al comienzo de cada párrafo intentaba dar pié y aclarando sobre el nuevo tema pero luego me hice bolas.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Es cuestión de gustos, a mi me parece más fácil de escribir y leer si solo tengo :
delphi
[/quote]
Por eso yo ya me digo... ¿y si lo dejamos a opción de que el pogramador lo configure? Solución salomónica y nos evitamos seguir en la misma. Que venga el próximo debate.
[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Lo veo más sencillo, y más fácil de aprender. Creo que la gente se animaría a programar más POO con esta sintaxis. Hay que pensar en el usuario novato. La curva de aprendizaje en Delphi es demasiado pronunciada al principio. Recuerdo que mucha gente se asustaba al conocer el lenguaje, y optaba por soluciones con una curva mucho más suave como Visual Basic (con el que es un juguete empezar a hacer código útil), sin saber que todas esas facilidades iniciales las acabarían pagando con sangre más adelante (si lo sabré yo, que sufrí VB, por obligación de una empresa donde trabajé, durante cinco años para olvidar).
Admito que si miras el código fuente en bruto de cualquier clase con esta sintaxis, en seguida se vuelve intratable. Pero es que nunca tratamos (o deberíamos tratar) con el código en bruto, ni siquiera me acuerdo de la última vez que saqué un listado de código, siempre trabajamos dentro de un IDE. Y para cualquier IDE debería ser bien sencillo mostrar de una forma rápida las declaraciones. Ya sea con una política minimamente inteligente de colapsar las secciones con código, ya sea con una ventana adicional, del estilo del inspector de objetos, que en este caso sería un inspector de clases declaradas, etc. ...
Saludos.
[/quote]
Fácil y difícil son términos abstractos y cada quien lo mide con su propia regla. La sintaxis de Delphi es lo suficiente entendible y sencilla de asimilar. Para alguien que en su vida a programado puede que le cueste... pero si ha tenido formación con Pascal, e incluso me animo a decir con VB, le resultará bastante intuitivo de ambos modos pero le resultará extraño ver como dentro de una clase se está declarando código cuando en realidad está declarando un método.
El estándar exige que se definan los métodos y luego se los implemente. No veo el porqué debamos cambiarlo. ¿Funciona? Si...
Ahora si tu deseas que por cuestriones de IDE y de visualización se muestre de la forma que tu comentas eso es otra cosa.
Yo considero que esos cambios van más allá del IDE sino que afectarán la forma de trabajar, en el diseño del compilador, y habrá que cambiar demasiado. Si hay algo que me alegra mucho y que han sabido cuidar mucho en Borland, CodeGear y Embarcadero, es la compatibilidad hacia atrás y que las cosas se mantengan uniforme de una versión a otra. No como .NET que el cambio de una versión a otra hace tronar todo y resulta más incompatible que una pareja entre un ganzo y una yegua.
El problema de los componentes que dices, es el problema que llamo componentitis aguda. Eso, mi amigo, es ajeno a Delphi... ya es problema de terceros, de los creadores que no supieron como mantener el soporte de una versión a otra. Por ello se debería primar el uso de los componentes oficiales antes que los de terceros.
Aunque claro, no me opongo a la idea y la magnífica funcionalidad y todo un acierto que nos aporta Delphi de extender la VCL y añadir más componentes y bibliotecas.
El gran aciertto de Delphi es la gran portabilidad de una versión a otra. Ha decir verdad, la cirugía mayor y necesaria hoy en día es la de soporte multiplataforma. Lo que estamos discutiendo son nimiedades. No veo razón para seguir dándole más cuerda al asunto.
Lo nuestro ya roza los límites de querer que la herramienta se ajuste a nosotros y forzar a la herramienta a nuestros propios intereses.
Saludos,
la verdad es que no tenia idea que este tema lograria sacar tantas cosas buenas.
