70 replies to this topic

[Marc]

Pues no debe ser tanta broma a judgar por la repercusión que han tenido. En realidad la sintaxis puede ser muy legible, tanto como cualquier lenguaje de alto nivel, y sobre todo en C++. Siempre que se programa a bajo nivel, en el lenguaje que sea, el código se vuelve mas ilegible y al delphi también le pasa. Y ¿que me dicen del asm?. Cada lenguaje tiene su lugar.

Sí, tienes razón en que en C también se puede hacer código perfectamente legible. Eso depende del programador. El problema no es que tu escribas o no escribas código legible, el problema es que un mal programador puede escribir cuatro simples líneas en C que te tengan mareado durante horas (y encima ese personaje se creerá muy listo por haber logrado condensar así su código).

Por eso me gusta tanto el Pascal (y todos sus derivados), no solo porqué sea más sencillo entender tu propio código, sino porqué es inmediato comprender el código de los demás.

Ni el peor programador del mundo podría escribir nunca un código en Pascal tan imposible de rastrear como un mal código C.

Personalmente, aunque me gusta delphi, prefiero el C y para mí es mas sencillo usarlo a bajo nivel, lo veo todo mas claro. Debe ser que mi nivel de ofuscación es muy alto y me permite sincronizar... (es broma, Marc)

No sé si estar de acuerdo contigo con esto.

Aunque Delphi (o Pascal) es más parecido al lenguaje natural, y al lenguaje pseudo-código, no creo que ello signifique que sea un lenguaje de más alto nivel que C. Creo que a nivel de complejidad, C y Pascal son lenguas del mismo nivel, y el código ensamblador resultante es también de la misma complejidad.

Aunque realmente hablo por ejemplos que recuerdo de traslación de Pascal a ensamblador de cuando estudiaba en la Universidad (hace varios siglos, parece). Pero como en la programación que he hecho en el mundo real nunca me he preocupado del código máquina resultante, puesto que siempre he obtenido un rendimiento aceptable, entonces no puedo hablar por experiencia propia.

Pero hasta donde tengo entendido y hasta donde vi cuando me preocupaban estos temas, a pesar de ser más inmediato de leer el código Pascal es del mismo nivel que el código C y obtienen un ensamblador de la misma calidad y rendimiento.

NOTA: A menos que te pongas a hacer perrerías en el código, cosa que en Pascal no se puede hacer, pero que el C parece que te invite a ello. Me refiero a acceder directamente a la memoria obviando los tipos declarados de los datos a los que accedes, o modificar directamente la pila de ejecución, etc. ... Naturalmente con estas prácticas tan dudosas puedes disparar el rendimiento de tu aplicación, pero me pregunto cuantas veces está esto justificado (puesto que en estos casos es evidente que la legibilidad del código se va a la porra, y más te vale documentar bien las trastadas que haces, puesto que seguirlo por el código fuente se convierte en una odisea digna de un héroe homérico).

[egostar]

Cuando yo me metí a este asunto de la programación me enseñaron Ensamblador, Basic, Cobol, Pascal, Fortran, RPG y desde esa época me gustó Pascal por sobre los demás y por aquellos asuntos de la vida que no se puede uno explicar, comencé a trabajar con Turbo Pascal y de ahí hasta hoy no lo he abandonado.

Por supuesto he aprendido otros lenguajes y otras herramientas, pero programar con Delphi es lo que realmente me gusta hacer, creo que ahí está la principal diferencia entre un desarrollador Delphi y los desarrolladores de otras herramientas, que suelen ir por el lenguaje de moda y por supuesto monetario $$$$$$, pero que no echan raíces en ninguno.

Y como dice el comercial, programar por placer no tiene precio.........

Salud OS

[Khronos]

Mi primer lenguaje de programación fue Delphi y ahora tengo un nivel aceptable de C/C++. A medida que aprendo nuevos lenguajes, veo cosas obsoletas en Delphi, en cuanto a la sintaxis, aunque me duela reconocerlo.

La estructura cerrada que tiene el código Delphi:

delphi

unit Unit1;
 
interface
 
uses SysUtils;
 
implementation
 
end.

Cuando empecé a programar, me pareció muy buena esta estructura, ya que te obligaba a respetarla y a seguir ciertas pautas para programar. Pero ahora veo ese código, y me parece ridículo. De esas 5 líneas sólo hace algo unas de ellas. Después, el archivo principal del programa: el .dpr. Cuando llevas tiempo programando en Delphi, sabes lo que es, pero si acabas de empezar y ves un archivo .dpr y muchos archivos .pas, sólo te confunden.

Lo que principalmente critico de Delphi es su estructura obsoleta de los años catapún, Object Pascal fue actualizándose y añadiendo nuevas funcionalidades pero su estructura siguió siendo la misma... Otra cosa que no me gusta mucho es como añadir librerías con el método Uses.

Creo que es todo lo que tengo que criticar de Delphi, porque tiene muchas más cosas buenas. Lo que más me gusta son los getters y los setters de los objetos. Los objetos en Delphi son bastante más complejos que en cualquier otro lenguaje, pero mucho más potentes, con su parte privada, protegida, pública, propiedades...

Si existiera el lenguaje perfecto, yo creo que sería una mezcla de Delphi y C...

Delphi o se hace multiplataforma y con soporte para otros procesadores o muere...

[Delphius]

Hola,
Yo recibí una educación pascalera.
Fue el primer lenguaje que me enseñaron, luego pasé por Delphi, Visual Basic, algo de .NET. La historia ya la saben.

Yo no soy el más adecuado para opinar puesto que no ido mucho más allá, pero de lo que he podido curiosiar de otros lenguajes, entre ellos C, la verdad es que prefiero a mi Delphi.
Por cosas de la vida me ví trasteando un tiempo en un viejito llamado Cobol. Y lo poco que ví me gustó aunque fuese un tanto engorroso adaptarme. Hace unos cuantos meses por necesidad propia tuve que estudiar un poquito de FORTRAN para comprender un tema que estaba estudiando.

He visto código en Basic, en Java, Cobol, Fortran, .NET, C#, C/C++, además de mi querido Pascal/Object Pascal y si bien se con tiempo y más ganas podría aprender a cualquier lenguaje C o derivado de éste Delphi/Object Pascal tiene un encanto natural que realmente me invita a seguir en él y aprender las cosas poniendolas en práctica en él.

Saludos,

[Delphius]

Hola Khronos,

No comprendo... ¿cuál es el problema de esa estructura? ¿Estructura obsoleta? ¿En que sentido? ¿Cómo crees entonces que debe añadirse unidades o bibliotecas?

Si te explicas mejor quizá logre entender el punto.

Te aviso Khronos que hay cosas que no se pueden ni DEBEN cambiar en un lenguaje. Son parte de su estándar. Así como existe un estándar ANSI C para los compiladores e IDEs para C existe un estándar ANSI-ISO a seguir para Object Pascal. No podemos salirnos de él puesto que sería violar el estándar.

En todo caso ya se estaría hablando de un fork, de iniciar una nueva rama.

Saludos,

[Khronos]

Hola Delphius,

Digo que es una estructura obsoleta porque hay cosas que no sirven para nada en Delphi, de hecho provocan problemas. Por ejemplo: Tienes la unidad Prueba.pas, la primera línea de esa unidad es Unit Prueba;. Si le quieres cambiar el nombre a la unidad, tienes que cambiar el nombre al fichero y modificar la primera línea del archivo.
La palabra reservada Interface, a continuación de ella, introduces las unidades con Uses; me parece totalmente inútil. Lo mismo sucede con Implementation.
Otro detalle, es que la estructura del archivo .dpr y la de los .pas sea totalmente distinta. Los .dpr (Delphi Project) no tienen interface, implementation, etc... Además, en el archivo .dpr no se puede hacer esto:

delphi

program MiPrograma;
 
uses SysUtils;
 
procedure Proc2; //No se puede hacer...
 
procedure Proc1;
begin
  Proc2;
end;
 
procedure Proc2;
begin
 
end;
 
begin
 
end.

Si tienes este orden en la declaración de procedimientos/funciones y desde Proc1 quieres llamar a Proc2 no puedes hacerlo, a no ser que pongas Proc2 encima de Proc1 o en otra unidad.

En cuanto a las unidades, en C/C++ puedes hacer algo como esto:

c

#include "sys/myproject/system.h"

En Delphi, en las unidades .pas no se puede hacer, no es una limitación importante pero en C si tienes un proyecto muy grande y lo quieras separar en módulos con subcarpetas se agradece.

Si es cierto, que hay cosas que no se pueden cambiar de un lenguaje; pero tienes el claro ejemplo de Python 2.7 y Python 3.1.x, entre ambos hay un mundo que los separa.
Pero se podría poner como opcional poner lo de unit, interface, implementation en Delphi. Es decir, se podrían poner varias opciones para realizar una misma cosa. Por ejemplo: para llamar a un procedimiento/función que no tiene ningún parámetro se puede llamar de estas 2 formas:

delphi

Proc;
Proc();

Otro ejemplo son las funciones. Para devolver un valor se puede hacer así:

delphi

function Algo: integer;
begin
 Result:= 5;
 Algo:= 5;
end;

Son opciones, que enriquecen un lenguaje...

Saludos.

[Marc]

Estoy totalmente de acuerdo en que la lenguaje de Delphi le iría divinamente una buena reestructuración.

Por ejemplo, toda la sección de interface también soy de la opinión que debería desaparecer. ¿ Que necesidad hay de andar copiando continuamente líneas arriba y abajo entre declaración e implementación ?. Dentro de la sección de implementación ya hay toda la información que ponemos manualmente en la sección de interface, por tanto esta sección es totalmente innecesaria.

¿ Que a alguien le gusta poder ver todas las declaraciones juntas ?, pues que el IDE tenga una ventana (del tipo del inspector de objetos, ...) que te muestre agrupadas las declaraciones del código, esto es especialmente útil para ver de un vistazo una clase, ya que al tener agrupado código y declaración en la sección de implementación, es difícil hacerse una idea global de la misma.

Lo de que la primera línea "Unit Prueba" es totalmente innecesaria, también tiene razón Khronos.

Lo que no veo de tanta utilidad son los includes de C, la verdad es que en C ya les tenía mucha manía como para querer verlos ahora en Delphi (aunque quizás no sé ver su verdadera utilidad).

Otra cosa que le vendría muy bien a Delphi es coger características de otros lenguajes.  Copiar lo bueno que han introducido otra gente.

Por ejemplo, me gusta como en C# no hay archivos del tipo .dfm, sino que todas esas propiedades que en Delphi se almacenan en el .dfm y se cargan al crear el formulario, en C# el RAD las asigna por código en el Create del formulario. Eso me parece muy elegante y simplifica la consulta, lo tenemos todo en el archivo de código, no hay que ir a mirar en archivos diferentes.

Otra cosa buena a copiar del C# sería que tengo entendido que a los eventos de un control les puedes asignar más de una función. Es decir que al OnChange de un TEdit,le puedas enlazar a la vez los eventos Validar(), CambiarPuntosPorComas() y ConsultarDetalle(); Y que se ejecuten los tres, uno detrás de otro, al cambiar el contenido del TEDit.

Y ocultar de una vez los controles de un formulario para que no sean visibles desde otros formularios, implementar una verdadera herencia múltiple, etc. ... ...

En fin, innovar y mejorar el lenguaje y no solo el IDE, el compilador, los controles, etc. ..., que da un poco de vergüenza la de años que han necesitado para incorporar el for each al lenguaje.

[Khronos]

Por ejemplo, me gusta como en C# no hay archivos del tipo .dfm, sino que todas esas propiedades que en Delphi se almacenan en el .dfm y se cargan al crear el formulario, en C# el RAD las asigna por código en el Create del formulario. Eso me parece muy elegante y simplifica la consulta, lo tenemos todo en el archivo de código, no hay que ir a mirar en archivos diferentes.

Eso me parece excelente en C#, de hecho cada vez me gusta más este lenguaje. En Delphi los archivos .dfm se guardan en los recursos del ejecutable final y se cargan los .dfm en tiempo de ejecución y se interpreta la posición de los controles. Es un proceso muy rápido, pero si utilizaran el método que se emplea en el Visual Studio, sería todavía más rápido y se reduciría en gran medida el tamaño de los ejecutables.

El creador del lenguaje C# trabajaba en Borland con Delphi, y uno de los lenguajes en los que se inspiró fue en Delphi. Su nombre es Anders Hejlsberg.

[Marc]

Eso me parece excelente en C#, de hecho cada vez me gusta más este lenguaje. En Delphi los archivos .dfm se guardan en los recursos del ejecutable final y se cargan los .dfm en tiempo de ejecución y se interpreta la posición de los controles. Es un proceso muy rápido, pero si utilizaran el método que se emplea en el Visual Studio, sería todavía más rápido y se reduciría en gran medida el tamaño de los ejecutables.

El creador del lenguaje C# trabajaba en Borland con Delphi, y uno de los lenguajes en los que se inspiró fue en Delphi. Su nombre es Anders Hejlsberg.

Lástima que esté basado en C. Tiene cosas muy buenas, pero cada vez que he intentado aprenderlo (tampoco he insistido mucho, puesto que estoy muy contento con Delphi), la sintaxis me ha echado totalmente para atrás.

Por ejemplo, una de las cosas que proponías, es que en Delphi se pueda hacer :

delphi

function Algo: integer;
begin
 Result:= 5;
 Algo:= 5;
end;

Y yo no estoy de acuerdo con esto. No veo ninguna ventaja sustancial en ello y prefiero que solo haya una forma de hacerlo. En cambio en C# hay demasiadas formas de hacer algunas cosas y eso me parece totalmente contraproducente para tener un código fácilmente legible y poder entender sin problemas lo que otros programan.

En un lenguaje totalmente nuevo podrían haber escogido una única sintaxis, más rígida, en lugar de ofrecer tantas alternativas para satisfacer a los usuarios que provienen de C y están acostumbrados y esperan esa flexibilidad.

Así que por ahora, si algún día dejo Delphi, dudo que pase directamente a C#, si acaso antes miraré Python y otras alternativas.

[Delphius]

A ver muchachos,
La sección interface e implementation están para definir la visibilidad. Son necesarias para establecer los límites entre lo que será visible al exterior y lo que no quieren que se sea.

Si desaparecen, ¿Cómo ha de de declararse o indicarse que será público y que privado? 

Comparto en parte en que es una pequeña molestia estar redeclarando en interface lo que se ha definido en implementation. En todo caso lo que debería ajustarse es que no necesite estar redeclarando los métodos de una clase todo sino con indicar las clases.

Algo como:

delphi

interface
 
Const;
// las constantes...
 
Types;
// los tipos....
 
Classes;
// las clases

Y dejar escrita todo el cuerpo de la clase en implementation.
Comprendo su visión de que eso puede ser redundante, pero vamos... ustedes quieren que se elimine. Estoy seguro que eliminar no es la palabra y el mensaje que quieren transmitir ¿no creen? 

Khronos no entiendo a lo que comenta sobre la sección uses... ¿Cómo es eso que no se puede tener el proyecto bien armado y organizado en carpetas?

Marc, ¿Podrías explicar como eso de que en C# no hay archivo .dfm? ¿Entonces como y donde específicamente guarda la información?

Saludos,

[Marc]

Hola Delphius.

Respecto a las secciones interface e implements, me refiero a que se podrían fusionar perfectamente en una única sección (y que por tanto no habría ni que declarar).

Ejemplo de como propongo que debería quedar el código para un formulario sencillo con la aplicación de "Hola Mundo" :

delphi

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;
 
type
  TfrmPrueba = class(TForm)
  private
    lblMensaje: TLabel;
    btnPulsar: TButton;
    procedure btnPulsarClick(Sender: TObject);
    begin
      lblMensaje.Caption := 'Hola Mundo';
    end;
  public
  end;
 
end.

Respecto a como evita los archivos .dfm el C#, pues en lugar de poner sus propiedades en ese archivo, lo que va haciendo es añadirlas como código en el OnCreate del formulario.

Es decir que aplicando eso, tendríamos el formulario anterior de esta forma (sin necesidad ya de ningún archivo .dfm)

delphi

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;
 
type
  TfrmPrueba = class(TForm)
  private
    lblMensaje: TLabel;
    btnPulsar: TButton;
    procedure FormCreate(Sender: TObject);
    begin
      Self.Caption := 'Aplicación de Prueba';
      lblMensaje := TLabel.Create(Self);
      lblMensaje.Left := 100;
      lblMensaje.Top := 100; 
      lblMensaje.Caption := 'Mensaje';
      btnPulsar := TButton.Create(Self);
      btnPulsar.Left := 150;
      btnPulsar.Top := 150;
      btnPulsar.Width := 75;
      btnPulsar.Height := 25;
      btnPulsar.Caption := 'Pulse aquí';
      btnPulsar.OnClick := btnPulsarClick; 
    end;
    procedure btnPulsarClick(Sender: TObject);
    begin
      lblMensaje.Caption := 'Hola Mundo';
    end;
  public
  end;
 
end.

El mismo IDE se encarga de sincronizar los cambios que hagas en modo de diseño con el código en el OnCreate (y si no me equivoco, eso funciona en los dos sentidos, de manera que los cambios que se hagan en el código del OnCreate se aplican automáticamente al formulario abierto en tiempo de diseño).

¿ Que te parecería si nuestros formularios en Delphi ahora se viesen de esta forma ?

NOTA: Como antes dije que querría que los eventos pudieran tener una cola asignaciones, y no una única asignación, yo cambiaría la linea

btnPulsar.OnClick := btnPulsarClick;

por

btnPulsar.OnClick.Add(btnPulsarClick);

[Delphius]

Hola Marc,
¡Sin pelos en la lengua te dijo que me parece una total burrada semejante cosa!
Mil disculpas Marc pero eso no me parece para nada útil... es más engorroso y confuso.

1. No hay esquema u orientación alguna de la visibilidad de la clase. ¿La clase es privada o pública?
2. Se está mezclando el diseño y la declaración con la implementación de la misma. Una cosa es armar y diseñar el esqueleto de la case y otra ya es ponerle los órganos, los músculos, y la sangre.

Puedo aceptar y hasta me parecería algo elemental, obvio, sencillo y fácil de entender lo siguiente:

delphi

interface
 
Classes
  MiClase; // hacemos que la clase sea pública
 
...
 
implementation
 
type
  MiClase = class
  private
  ....
  public
    procedure Foo;
  end;
 
procedure MiClase.Foo;
begin
end;

Esto está conforme o al menos mucho más conforme al estándar ANSI-ISO de Object Pascal que tu alternativa.
Como se aprecia, en implementation se define la clase y se implementan los métodos. Luego, si la clase debe ser visible para las otras unidades se añade la clásula Classes (haciendo cierta analogía con la sección uses) y listo.
Planteo similares se puede llevar para constantes, variables, eventos y otros tipos.

Lo de hacer que en la propia implementación y diseño de una clase esté declarado lo que va en el dfm en vez aportar claridad, la está ofuscando.... ¡se está mezclando el diseño de la misma con los datos que representa a un objeto, o para que quede más claro y evidente: con la instancia de la clase!

Eso no suena nada OO, ni respeta a las buenas prácticas.
El streaming funciona perfectamente en Delphi, no veo motivo el porqué tocarlo.

Lo de de evento múltiple estoy en duda. Puede que sea interesante... aunque lo veo un tanto engorroso. Se estaría cambiando un poco la filosofía y los principios que definen a un evento y se estaría elevando el contexto: en vez de definirse un evento se estaría definiendo una familia de eventos. Si se ha definirse una familia de eventos entonces debería haber cierta naturaleza en común entre todos los eventos a realizar pero los nombres que tu sugieres no van en la misma sintonía.

Me estoy preguntando cuál sería el propósito de ello.

Saludos,

[felipe]

Solo algo a comentar desde mi poco conocimiento a C#, como comenta Marc, se evitan los archivos *.dfm al crear los componentes, la pregunta mía es ¿se aprecia el código de su creación como en el ejemplo?... porque si es así, me parece un caos, obvio, no estoy diciendo que todo ese texto este visible, si no lo está ¿para que tenerlo allí? y si está... no imagino en Delphi un archivo *.pas en el que tengamos que bajar 3 páginas de declaraciones de componentes para llegar a los procedimientos, me parece engorroso.

Al contrario, la forma en que está me parece ordenado, ¡que importa un 1k de más!. Es como si en tu armario tuvieras los pantalones y camisas juntos en el mismo lado.


Saludos!

[Marc]

Solo algo a comentar desde mi poco conocimiento a C#, como comenta Marc, se evitan los archivos *.dfm al crear los componentes, la pregunta mía es ¿se aprecia el código de su creación como en el ejemplo?... porque si es así, me parece un caos, obvio, no estoy diciendo que todo ese texto este visible, si no lo está ¿para que tenerlo allí? y si está... no imagino en Delphi un archivo *.pas en el que tengamos que bajar 3 páginas de declaraciones de componentes para llegar a los procedimientos, me parece engorroso.

Al contrario, la forma en que está me parece ordenado, ¡que importa un 1k de más!. Es como si en tu armario tuvieras los pantalones y camisas juntos en el mismo lado.


Saludos!

Hola Felipe.

En los RADS modernos de Delphi tienes unos botones (+) para colapsar el código de un procedimiento, o para desplegarlo.

Tienes toda la razón en que cuando abrieras un formulario las primeras páginas serían de la inicialización en el Form,Create (al igual que ya ahora en muchos formularios las primeras páginas son la declaración de controles en el formulario).

Pero con que la implementación del método Create esté colapsada al abrir el formulario, problema resuelto (es más, para mi gusto todas las implementaciones deberían estar colapsadas, de forma que sería mucho más rápido localizar un código que estés buscando). Imagino que eso mismo es lo que hará C# en Visual Studio, aunque debo admitir que hace siglos que no lo utilizo.

De la misma forma, iría bastante bien que la declaración del formulario también esté colapsada, porqué a veces ocurre lo que dices, que tiene tantos controles que te estás un buen rato dándole a bajar página hasta llegar a donde quieres.

[Marc]

Hola Marc,
¡Sin pelos en la lengua te dijo que me parece una total burrada semejante cosa!
Mil disculpas Marc pero eso no me parece para nada útil... es más engorroso y confuso.

No tienes porqué disculparte, es lógico que tengas tu opinión, precisamente para los gustos se inventaron los colores. Por eso aunque personalmente te pueda parecer una gran burrada (tan respetable como cualquier otra opinión), no todo el mundo va a pensar lo mismo.

¿ Cual es el lenguaje más elegante y mejor estructurado en la actualidad ?, creo que mucha gente coincidiría en nombrar a Eiffel. Y Eiffel sigue precisamente este enfoque de integrar la declaración y la implementación (igual que Python, y tantos otros).

1. No hay esquema u orientación alguna de la visibilidad de la clase. ¿La clase es privada o pública?

¿ Clases privadas ?. ¿ En Delphi tenemos clases privadas ?. Siempre se aprende algo nuevo, nunca las había visto, en cualquier caso, de existir, funcionarían exactamente igual, puesto que la única diferencia en mi propuesta es que la implementación está integrada en la declaración en lugar de posponerla en una sección posterior.

Lo que sí que conozco es que en Delphi tenemos atributos y métodos privados, y como puedes ver en el ejemplo que he propuesto, se sigue manteniendo exactamente igual. Y es que la estructura de la sección de declaración no ha variado nada.

En mi propuesta todo el tema de visibilidad funciona exactamente igual que en el ObjectPascal tradicional.

2. Se está mezclando el diseño y la declaración con la implementación de la misma. Una cosa es armar y diseñar el esqueleto de la case y otra ya es ponerle los órganos, los músculos, y la sangre.

No veo el problema en mezclarlo. Y como te comentaba muchos lenguajes Pascaleros modernos de reconocido prestigio por su elegancia (como Eiffel y Python) optan por esta solución.

El streaming funciona perfectamente en Delphi, no veo motivo el porqué tocarlo.

¿ Nunca has tenido que tocar directamente el .dfm ? Yo sí lo he necesitado bastantes veces, y preferiría que estuviera en el mismo código Pascal que el resto del programa. Aparte de que me parece una solución mucho más elegante que el actual Streaming del valor inicial de propiedades de los objetos.

Todo estaría en código Pascal que puedes tocar y adaptar si es necesario, en cambio el streaming de los valores en el archivo .dfm es algo que funciona automáticamente y sobre el que no puedes interferir.

Lo de de evento múltiple estoy en duda. Puede que sea interesante... aunque lo veo un tanto engorroso. Se estaría cambiando un poco la filosofía y los principios que definen a un evento y se estaría elevando el contexto: en vez de definirse un evento se estaría definiendo una familia de eventos. Si se ha definirse una familia de eventos entonces debería haber cierta naturaleza en común entre todos los eventos a realizar pero los nombres que tu sugieres no van en la misma sintonía.

Evidentemente ahora los eventos serian TCollections, y según la clase se definiría los eventos que se pueden enlazar.

Es decir, el evento OnChange de un TEdit sería una simple TCollection de TNotifyEvent

En cambio el evento AfterScroll de un TQuery seria una TCollection de TDatasetNotifyEvent

Me estoy preguntando cuál sería el propósito de ello.

¿ De verdad nunca lo has necesitado ?. Sí que soy una persona rara puesto que yo lo he necesitado miles de veces.

Supón que tienes un formulario de búsqueda, con cuatro TEdits. Cada vez que se modifica uno de estos TEdits se lanza una consulta SQL y se ve su resultado en una Grid.

Evidentemente has de tener un procedimiento del tipo "BuscarDatos" asociado al evento OnChange de los cuatro TEdits.

Ahora imagina que dos de esos TEdits lo usamos para entrar valores numéricos (por ejemplo los importes inferior y superior de las facturas que estamos buscando). E imagina que además estamos usando un TEdit estándar, por lo que los usuarios pueden entrar cualquier carácter. Así que a esos dos TEdits les querremos poner un evento OnChange donde controlar que no se entren carácteres no numéricos.

Así tendremos que los dos primeros TEdits tienen un evento OnChange para llamar a "BuscarDatos"

Mientra que los dos segundos TEdits tendrán dos llamadas en el evento OnChange. Primero se llamaría a "VerificarValorNumérico" y después a "BuscarDatos".

NOTA: Ya sé que ahora mismo esto se puede programar haciendo un procedimiento intermedio. Es decir programando un procedimiento en el evento OnChange desde el que se llame tanto a "VerificarValorNumerico" como a "BuscarDatos". Pero todo lo que sea tener que poner estos procedimientos intermedios es engorroso, poco elegante y propenso a inducir bugs. La solución de poder encadenar varias llamadas en un evento, es mucho más elegante (por eso lo han implementado así en C#, son las ventajas que tiene el poder crear un lenguaje desde cero).

[luk2009]

Hola Marc,
¡Sin pelos en la lengua te dijo que me parece una total burrada semejante cosa!
Mil disculpas Marc pero eso no me parece para nada útil... es más engorroso y confuso.

No tienes porqué disculparte, es lógico que tengas tu opinión, precisamente para los gustos se inventaron los colores. Por eso aunque personalmente te pueda parecer una gran burrada (tan respetable como cualquier otra opinión), no todo el mundo va a pensar lo mismo.

Pues yo creo que no solo mereces una gran disculpa, sino que mereces que se retire ese comentario. Se sabe que cuando se comienza a insultar y a lanzar improperios es porque faltan argumentos para defender tu posicion. Como no creo que este sea el caso, no veo la necesidad de ese comentario. Mucho menos para una persona tan respetuosa como Marc y todavia menos viniendo de una personas con tantas luces como delphius.

No creo que aporte al debate el descalificar asi las opiniones de otros.

[Marc]

Pues yo creo que no solo mereces una gran disculpa, sino que mereces que se retire ese comentario. Se sabe que cuando se comienza a insultar y a lanzar improperios es porque faltan argumentos para defender tu posicion. Como no creo que este sea el caso, no veo la necesidad de ese comentario. Mucho menos para una persona tan respetuosa como Marc y todavia menos viniendo de una personas con tantas luces como delphius.

No creo que aporte al debate el descalificar asi las opiniones de otros.

Luk, a mi no me parece ningún insulto personal, ni descalificación, y no lo he tomado como tal. Está opinando sobre una propuesta de modificación de ObjectPascal que ha introducido Khronos y yo he defendido. Es muy lícito que a Delphius esa propuesta le parezca una burrada (que esta valoración no me parezca poco respetuosa quizás dice mucho del nivel medio de educación al que lamentablemente nos hemos acostumbrado en España). Además creo que lo ha intentado argumentar bastante bien (aunque no comparto esos argumentos).

Cosas peores dije yo sobre los creadores de Delphi y algunas características del lenguaje, en un debate reciente (no le puedo pedir moderación a Delphius, cuando yo llamé chapuza al mecanismo de sobreescritura de métodos de Delphi, e incompetentes y perezosos a los programadores que lo implementaron).


Lamentablemente nada de lo que digamos aquí va a influir en el desarrollo del lenguaje, así que estos debates, aunque muy interesantes, son totalmente estériles. Y esto si que me parece una pena.

[Khronos]

Cada persona tiene distintos puntos de vista, como es natural.

Lamentablemente nada de lo que digamos aquí va a influir en el desarrollo del lenguaje, así que estos debates, aunque muy interesantes, son totalmente estériles. Y esto si que me parece una pena.

Tienes razón Marc, yo lo considero un debate sano para saber los puntos de vista que tiene la gente.

Cambiando de tema, en el ranking se puede ver como creció el lenguaje de programación de google: go. Estoy esperando que se termine el port del compilador para sistemas Windows, ya que sólo existe la versión para Mac OS X y GNU/Linux. Las características que tiene el lenguaje me parecieron muy interesantes, es una mezcla de C++ y de Delphi combinando los puntos fuertes de cada lenguaje.

La declaración de variables es similar a Delphi:

delphi

var s string = ""

El operador de asignación es :=, los punteros y arrays son como en C, para definir tipos y clases se utiliza el type de Delphi y empieza a tener mucha documentación este lenguaje...

delphi

func newFile(fd int, name string) *File 
{
        if fd < 0 {
            return nil
        }
        return &File{fd, name}
}

Cada vez me tienta más este lenguaje...

Saludos.

[felipe]

Hola Felipe.

En los RADS modernos de Delphi tienes unos botones (+) para colapsar el código de un procedimiento, o para desplegarlo.

Es verdad Marc, había pasado eso por alto, hoy en día es algo muy común y verdaderamente práctico.

Aunque no descarto la opción de que se mantenga como está.
Por ejemplo, en el caso de JAVA, he visto programadores que aún cuándos sus IDE permiten colapsar este código, prefieren separar la parte visual de la parte lógica, eso sí, teniendo en cuenta además lo complejo que es dicho manejo en este lenguaje.


Saludos!

[egostar]

Yo propongo esta nueva clasificación.

Salud OS

Attached Files

•  1939_3a139009dac9b629624abea5d51f69aaf7cebf15.png   13.5KB   7 downloads