70 replies to this topic

[Fenareth]

Yo propongo esta nueva clasificación.

Salud OS

Obtenida de....... ?

Saludox !

P.D. Me gusta más

[egostar]

Obtenida de....... ?

De la misma fuente,

Ya está agregada la nota

Salud OS

[Marc]

Yo propongo esta nueva clasificación.

Salud OS

Obtenida de....... ?

Saludox !

P.D. Me gusta más

De sumar el ranking de Delphi + Pascal + Object Pascal, imagino. Y es que son ganas de favorecer a unos lenguajes y perjudicar a otros el que Visual Basic sume junto a Basic, y en cambio para Delphi tengan valoraciones independientes.

[Fenareth]

Qué buena observación... me suena bastante más lógica...

Saludox !

[Delphius]

Hola,

Marc, el porqué "semejante burrada" es porque me ha soprendido que viendo y conociendo tu vasta experiencia y centradas opiniones hayas propuesto esa manera de estructurar código. Me ha llamado mucho la atención de ti, quien defiende una buena codificación, estructuración y uso del lenguaje y de la herramienta propongas esa mezcla.

No iba con la intención de insultar, sino de decir "hey... amigo no me sueltes esa burrada" "no puedes haber dicho semejante cosa". ¿Me explico?

Sabemos que las mezclas de bebidas nos puede caer mal, de modo similar considero que mezclar las secciones implementation e interface no es una buena práctica a seguir. Por más que existiera el botón +/- o "expand/collapse" (creo que así les llaman) para "ocultar" métodos, etc.

El paradigma y la manera en como se ha llevado la maduración de organizar código a evolucionado a ello: una correcta separación de interés, lo visual por un lado, código por el otro. Del mismo: declaración e implementación.

El código debe ser lo más limpio posible y fácil de leer. En tu propuesta se está ofuscando y tu amigo, supuestamente estás en contra de eso.

Lo de streaming va en la misma sintonía: lo que hace a los valores de las propiedades de los forms y controles en el archivo .dfm; sus declaraciones en el pas. ¿El porqué? Muy fácil: por un lado para organizar mejor las cosas, y en segundo lugar, y con mucha razón de peso, se está independizando lo que es la propia definición de una clase y sus miembros o atributos (recordemos que los controles y componentes se declaran como atributos de un form) de los valores que contiene la instancia de si misma.

En el .pas se está definiendo e implementando una clase. Cuando asignamos valores a las propiedades de ésta y a sus componentes estamos ya en un plano concreto: estamos definiendo un objeto de esa clase.
Es una correcta separación de intereses. Y como dije, está implementada de una forma bastante rápida y funciona bien.

No discuto que en ocasiones puede llevar a algunos problemas como indicas. Pero son problemas menores.

Respecto a lo de clases privadas y públicas sigo pensando en mi postura: se necesita de dicha distinción. Quizá una buena mayoría de las clases deban y serán públicas pero existen casos en que una clase debe ser privada o fuera del alcance público.
Voy a dar un ejemplo: clases intermedias que asisten a otras clases. Muchos frameworks tienen clases a modo Fachada que ocultan la implementación de otras tantas clases auxiliares. Esta clase Fachada es la puerta de acceso a un módulo y hace de nexo o puente entre el cliente y el framerork mismo. Por tanto es más que útil y deseable ocultar estas clases hacia afuera. La Fachada y/o otras clases de alcance público ofrecerán la interfaz necesaria y adecuada para que el cliente pueda trabajar cómodamente.

La alternativa que propuse, de una clásula Classes, va en ese sentido: asociar las clases que tendrán visibilidad pública.

Respecto a los eventos múltiples, entiendo tu ejemplo y como dices: se puede hacer con un método intermedio. Quizá si pueda ser una buena posibilidad y en cierto modo resulta atractiva esta posibilidad, pero todavía tengo mis reservas.

A mi modo de ver, no supone demasiado problemas el que el mismo evento llame un método intermedio y que éste asuma la responsabilidad de llevar las comprobaciones que comentas. En estos momentos no recuerdo si hay algún patrón que sugiera alguna solución para este caso de problema, pero seguramente si lo hay... son cientos los patrones y no resultaría difícil imaginarse que algo como esto ya se haya discutido y propuesto algún modo de resolverlo sin llegar a tener un esquema basado en Colecciones como el que describes.

Esto está fuera de mi análisis por lo que no sabría decir, no conozco demasiado en profundidad sobre todos los patrones. Apenas entiendo los principios de unos 15 con mucha suerte.

Saludos,

[Marc]

Hola Delphius.

No te preocupes que entendí perfectamente a lo que te referías con lo de burrada.

Me parece que te encierras demasiado a cualquier sugerencia de modificación de Delphi. Object Pascal no es perfecto, ningún lenguaje lo es. Las modificaciones que hemos sugerido son modificaciones que han implementado otros lenguajes más modernos (C#, Eiffel, Python, ...), y sus usuarios parecen muy satisfechos con ellas.

Tienes toda la razón en priorizar la legibilidad del código por encima de todo, para mi también es lo más importante. Prefiero de largo un código legible (y por tanto más fácil de mantener) que cualquier otro código, aunque tenga un rendimiento superior (y es que para el software que hacemos la mayoría, el rendimiento no es muy importante, hay que hacer auténticas burradas para que el rendimiento no sea "adecuado").

Llevas razón en que un código que integre declaración e implementación es más difícil de comprender a simple vista que un código que tenga ambas secciones separadas. Pero para ayudar en esto deberían venir los IDE's. Y un buen IDE que colapse la implementación y solo muestre la que quieras ver a cada momento, te permite darle la vuelta a la tortilla.

En este caso la legibilidad me parece la misma y la mayor simplicidad de escribir código con esa sintaxis animaría a los usuarios noveles a adentrarse más en la POO.

De la misma forma, el IDE puede ocultar y mostrar a voluntad el código para inicializar en el OnCreate las propiedades de los objetos en el formulario. Así que yo solo le veo ventajas a que esas propiedades estén en el mismo código Pascal que el resto del programa, en lugar de en un formato distinto como es el .dfm. Es más fácil de manipular.

NOTA: Aún no entiendo el problema con la visibilidad de las clases. ¿ Hay clases privadas ?, yo solo conozco que puedes variar la visibilidad de los métodos y atributos dentro de una clase, pero no sabía que se puede variar la visibilidad de la misma clase. Y además no veo en que influye mi sugerencia en ello, dejo absolutamente intacta la sección de declaración, por lo que las declaraciones tendrán las mismas funcionalidades que antes (la única diferencia es que la implementación ya no se posterga a una sección posterior).

La verdad es que no se si mis propuestas son juiciosas. A mi me lo parecen, pero puedo estar muy equivocado. Solo sé que me gustaría ver a una Embarcadero más ambiciosa que nos trajera a Delphi las características que se innovan en otros lenguajes y que nos dejan salivando de envidia. Creo que para mantener la compatibilidad de código hacia atrás, se frenan mucho a la hora de refrescar el lenguaje, y para mi eso es un error, me gustaría que cada cierto tiempo tuviéramos una pequeña revolución y le dieran una buena sacudida a Delphi (aunque eso implique que el código que escribiste en Delphi 5 ya no te sirva para Delphi 2012).

Saludos.

[egostar]

Bueno, es que la misma estructura de una Unit permite generar métodos y variables públicas (sección Interface) y privadas (sección Implementation) de forma directa incluso sin la necesidad de crear objetos.

Veamos un código sencillito:

delphi

unit Unit2;
 
interface
 
uses
  SysUtils, StrUtils;
 
var
  variablePublica: string;
 
  function funcionPublica(const a,b: integer): variant;
 
implementation
 
var
  variablePrivada: string;
 
  function funcionPrivada(const aPriv, bPriv: integer): variant;
  begin
    if AnsiUpperCase(variablePrivada) = 'SUMA' then
      result := aPriv + bPriv;
    if AnsiUpperCase(variablePrivada) = 'RESTA' then
      result := aPriv - bPriv;
    if AnsiUpperCase(variablePrivada) = 'MULTIPLICA' then
      result := aPriv * bPriv;
    if AnsiUpperCase(variablePrivada) = 'DIVIDE' then
      result := aPriv / bPriv;
  end;
 
  function funcionPublica(const a,b: integer): variant;
  begin
    variablePrivada := variablePublica;
    result := funcionPrivada(a,b);
  end;
 
end.

Y su llamada desde la unidad principal:

delphi

uses Unit2;
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  unit2.variablePublica := ComboBox1.Text;
  showMessage(unit2.funcionPublica(strtoint(Edit1.Text),StrtoInt(Edit2.Text)));
end;

Como podrán ver, no se puede acceder a la variable privada ni a la función privada, lo cual, desde mi punto de vista, le dá una razón de existir a dicha estructura, que no tiene que ver si llegase a ser obsoleta o no.

Salud OS

[Delphius]

Hola Marc,

Comparto contigo que Delphi debe empezar a asimiliar e incorporar nuevas cosas que ya han incorporado otros lenguajes... algo de eso ya se estuvo haciendo y se hizo. Recordemos el caso de los métodos genéricos (creo que ese es el nombre, no estoy totalmente seguro) que está basado en parte del método plantilla de Java y de C++.
De que Embarcadero debería prestarle atención, totalmente de acuerdo. Después de todo somos nosotros quienes utilizamos las herramientas y evaluamos y determinamos su viabilidad.

El asunto es que esos cambios deben ajustarse y calibrarse lo más posible al estándar y no afectar en gran medida la compatibilidad hacia atrás y de evitar posibles confusiones y errores.

Opiniones diferentes vamos a encontrar muchas veces, y ambos lo sabemos.

A mi modo de ver no es deseable eso de estar mezclando. Desconozco Eiffel y Phyton... poco se de ellos. Se que tienen una ascedencia hacia Pascal pero de allí en más, sobre su sintaxis, su semántica y diseño no se. Por ello evité toda opinión y referencia hacia ellos.
Mi defensa se basa en la clara evolución de los paradigmas: conseguir la mayor independencia entre las clases, entre código e interfaz y datos, entre lo que es definiciones e implementaciones.

La existencia del dfm va en ese sentido. En el .dfm queda definida la instancia de la clase definida y escrita en el .pas. Se ha buscado independizar la relación clase/objeto y eso me parece absolutamente correcto.

Cuando tu escribes un

TForm = class(TForm1)

En dicho pas, lo que estás haciendo es definir una clase. No un objeto.

El ver luego cosas como en tu ejemplo la asignación de algunas propiedades va en sentido contrario a la norma ya que se pierde sentido. Se ha pasado de definir una clase a definirse un objeto.

Se supone que en este paradigma existe distinción entre una cosa y la otra.
Disculpa si no me convence tu propuesta en esto.

Java tiene algo similar a Delphi en esto del .dfm, al menos eso es lo que tengo entendido. No uso C# por lo que no sabría decir como es que funciona lo que comentas.

Se que el IDE puede ofrecer funcionalidades y facilidades como la que comentas, pero en última en el codigo seguirá estando eso... por más que no lo veamos.

Si estoy de acuerdo a que es una redundancia, y un ligero error conceptual dicho sea de paso, que la definición de una clase esté en interface y su código en implementation.

Cuando definimos la clase, además la estamos implementando. Suena lógico por tanto que toda su declaración esté en implementation. Luego, si ha tenerse alcance público, en interface se podría llevar la lista de los debidos elementos (no sólo las clases).
¿El porqué está su declaración en interface? Porque el compilador necesita definir y tener acceso a su descripción a fin de determinar el alcance de su visibilidad.

Cuando se define la clase allí mismo estamos indicando que será privado, protegido, público y publicado de ésta. Por tanto es redundante...

Considero que la sección interface podría estar para llevar la visibilidad externa el resto queda oculto. Por ello sostengo que debe existir la sección interface e implementation.

Sobre la existencia de clases privadas u públicas... pues... existen amigo. Existen. De hecho es legal hacerlo en Delphi:

delphi

implementation
 
type
  MiClase = class
  private
    FCampo: Integer;
    procedure SetCampo(const value: integer);
    function GetCampo: Integer;
  public
    property Campo: Integer read GetCampo write SetCampo;
  end;
 
{ MiClase }

Como he dado, un ejemplo de caso práctico es la presencia de una clase fachada que es la clase visible, e internamente el resto de las clases. La Fachada da el resto a las demás y delega y reparte las funcionalides. Su nombre lo indica: la fachada es sólo una "interfaz" que lleva a que se centre en un punto todo el resto.

Una lectura al libro UML y Patrones sobre el patrón Fachada y el patrón Layers (Capas) te aportará una mejor visión del tema.

Ahora que lo pienso, quizá si esté demás definir en interface la subsección uses. Si nos fijamos, cuando hacemos File -> Use Unit el IDE automáticamente las declara en implementation. Lo que es correcto: tener acceso a tercera unidades para poder llevar a cabo la implementación de la en cuestión.
A menos que se quisiera dar visibilidad a alguna unidad aparte de la propia quizá sea un error. Creo que esto lleva a un punto a favor del comentario de Kronos.

De que es necesario de vez en cuando un proceso de reingeniería, eso no lo pongo en duda. La misma disciplina de Ingeniería de Software lo sugiere. Esto es aplicable cuando el diseño original ha absorbido demasiado cambios en un período razonable de tiempo. ¿Tanto ha absorbido Delphi en los últimos años? lo pongo en duda.

El cambio es cambio, y debe aceptarse. No es que esté en contra del cambio, sino que ese cambio sea lo más razonable y llevadero. Y no que lleve a un proceso cercano a una reingeniería completa que conduzca a una cirujía muy peligrosa. Tan peligrosa que tire años de trabajo por la borda.

Saludos,

[felipe]

Que bueno que este hilo lo viera la gente de embarcadero


Saludos!

[jorgeu]

Que bueno que este hilo lo viera la gente de embarcadero


Saludos!

Probablemente solicitarían primero los key de cada uno para autenticar la copia de delphi   

[felipe]

Que bueno que este hilo lo viera la gente de embarcadero


Saludos!

Probablemente solicitarían primero los key de cada uno para autenticar la copia de delphi   

...

mejor les decimos que nos quedamos en Turbo Explorer     



Saludos!

[Marc]

Hola egostar.

Bueno, es que la misma estructura de una Unit permite generar métodos y variables públicas (sección Interface) y privadas (sección Implementation) de forma directa incluso sin la necesidad de crear objetos.

Veamos un código sencillito:

delphi

unit Unit2;
 
interface
 
uses
  SysUtils, StrUtils;
 
var
  variablePublica: string;
 
  function funcionPublica(const a,b: integer): variant;
 
implementation
 
var
  variablePrivada: string;
 
  function funcionPrivada(const aPriv, bPriv: integer): variant;
  begin
    if AnsiUpperCase(variablePrivada) = 'SUMA' then
      result := aPriv + bPriv;
    if AnsiUpperCase(variablePrivada) = 'RESTA' then
      result := aPriv - bPriv;
    if AnsiUpperCase(variablePrivada) = 'MULTIPLICA' then
      result := aPriv * bPriv;
    if AnsiUpperCase(variablePrivada) = 'DIVIDE' then
      result := aPriv / bPriv;
  end;
 
  function funcionPublica(const a,b: integer): variant;
  begin
    variablePrivada := variablePublica;
    result := funcionPrivada(a,b);
  end;
 
end.

Y su llamada desde la unidad principal:

delphi

uses Unit2;
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  unit2.variablePublica := ComboBox1.Text;
  showMessage(unit2.funcionPublica(strtoint(Edit1.Text),StrtoInt(Edit2.Text)));
end;

Como podrán ver, no se puede acceder a la variable privada ni a la función privada, lo cual, desde mi punto de vista, le dá una razón de existir a dicha estructura, que no tiene que ver si llegase a ser obsoleta o no.

Salud OS

Es verdad, variables y funciones privadas en la Unit sí que se pueden tener. A mi lo que me perdía es que hablábamos de clases privadas, y siempre las he puesto en la sección types, al principio de la Unit, por lo que las declaraciones de las clases son siempre públicas (o eso creía).

Tienes razón, habría que hacer otro cambio para poder tener estas variables y funciones privadas. Aunque creo que la solución es bastante inmediata. Tu ejemplo quedaría :

Archivo de la unit Unit2

delphi

unit Unit2;
 
uses
  SysUtils, StrUtils;
 
public
 
var
  variablePublica: string;
 
  function funcionPublica(const a,b: integer): variant;
  begin
    variablePrivada := variablePublica;
    result := funcionPrivada(a,b);
  end;
 
 
private
 
var
  variablePrivada: string;
 
  function funcionPrivada(const aPriv, bPriv: integer): variant;
  begin
    if AnsiUpperCase(variablePrivada) = 'SUMA' then
      result := aPriv + bPriv;
    if AnsiUpperCase(variablePrivada) = 'RESTA' then
      result := aPriv - bPriv;
    if AnsiUpperCase(variablePrivada) = 'MULTIPLICA' then
      result := aPriv * bPriv;
    if AnsiUpperCase(variablePrivada) = 'DIVIDE' then
      result := aPriv / bPriv;
  end;
 
end.

[Marc]

Hola Delphius.

Cuando tu escribes un

TForm = class(TForm1)

En dicho pas, lo que estás haciendo es definir una clase. No un objeto.

El ver luego cosas como en tu ejemplo la asignación de algunas propiedades va en sentido contrario a la norma ya que se pierde sentido. Se ha pasado de definir una clase a definirse un objeto.

No coincido contigo aquí. Estamos hablando siempre solo de las clases formularios (y frames, ...). Solo en estas clases (las que ahora llevan archivo .dfm) se van a inicializar algunas de sus propiedades.

¿ Pero que problema hay en eso ?, yo no lo veo contra norma, ni definiendo un objeto. Muchas clases en su código de creación se inicializan y dan valores por defecto a sus atributos, ... Esto es lo que hacemos en mi propuesta en el evento OnCreate, inicializamos los formularios de esta clase, dándole sus valores por defecto.

Después ya está en manos de tu código el cambiar esos atributos para hacer que una instancia determinada sirva a las necesidades concretas de un momento determinado.

No sé en que se diferencia esto a cualquier otra clase de Delphi (que también se inicializan con valores predeterminados en su creación).

Java tiene algo similar a Delphi en esto del .dfm, al menos eso es lo que tengo entendido. No uso C# por lo que no sabría decir como es que funciona lo que comentas.

Yo tampoco uso C#, lo estudié pero su sintaxis es demasiado C para mi gusto, volví rápidamente a Delphi (por mucho que me queje, aún es de largo el lenguaje en el que me siento más cómodo).

Cuando definimos la clase, además la estamos implementando. Suena lógico por tanto que toda su declaración esté en implementation. Luego, si ha tenerse alcance público, en interface se podría llevar la lista de los debidos elementos (no sólo las clases).
¿El porqué está su declaración en interface? Porque el compilador necesita definir y tener acceso a su descripción a fin de determinar el alcance de su visibilidad.

Esto creo que ya lo hablamos hace poco, sinceramente las necesidades del compilador me tienen sin cuidado. No entiendo esta mala costumbre de Delphi de obligarnos a escribir de más solo para que el compilador tenga la información mascada.

El compilador no lo usaría nunca como argumento. Me niego a trabajar de más para ponerle las cosas más fáciles al compilador. Podemos discutir sobre legibilidad del código, funcionalidad, elegancia, etc. ... pero sobre el compilador no, el compilador que espabile un poco, es una herramienta a nuestro servicio, no somos los programadores quienes estamos al servicio del compilador (como cuando nos obliga a marcarle si un método es dinámico o virtual), si esa información la puede detectar él, no deberían obligarnos a declararla explícitamente.

Considero que la sección interface podría estar para llevar la visibilidad externa el resto queda oculto. Por ello sostengo que debe existir la sección interface e implementation.

Eso mismo ha comentado egostar. Le he sugerido una sintaxis explícita para public y private en la Unit, con un ejemplo.

Sobre la existencia de clases privadas u públicas... pues... existen amigo. Existen. De hecho es legal hacerlo en Delphi:

delphi

implementation
 
type
  MiClase = class
  private
    FCampo: Integer;
    procedure SetCampo(const value: integer);
    function GetCampo: Integer;
  public
    property Campo: Integer read GetCampo write SetCampo;
  end;
 
{ MiClase }

Como he dado, un ejemplo de caso práctico es la presencia de una clase fachada que es la clase visible, e internamente el resto de las clases. La Fachada da el resto a las demás y delega y reparte las funcionalides. Su nombre lo indica: la fachada es sólo una "interfaz" que lleva a que se centre en un punto todo el resto.

Delphius, en este ejemplo MiClase no es una clase privada, esta clase se puede utilizar por cualquier módulo que enlace esa Unit. Por tanto la clase es pública (hasta donde yo lo entiendo).

Y respecto a una clase fachada con métodos y atributos privados internos donde delega y reparte la funcionalidad, eso funciona exactamente igual con mi sugerencia de integrar declaración e implementación.

Lo siento, sigo sin ver ninguna diferencia entre la visibilidad de las declaraciones actuales en Delphi y las que se pueden conseguir integrando la declaración y la implementación.

El cambio es cambio, y debe aceptarse. No es que esté en contra del cambio, sino que ese cambio sea lo más razonable y llevadero. Y no que lleve a un proceso cercano a una reingeniería completa que conduzca a una cirujía muy peligrosa. Tan peligrosa que tire años de trabajo por la borda.

Saludos,

Creo que aquí es donde diferimos de verdad. A mi no me importaría ver de vez en cuando una buena sacudida en el lenguaje, aunque pierdas completamente la compatibilidad hacia atrás.

NOTA: Sinceramente, ¿ cuan útil es la compatibilidad hacia atrás ?. Cuando intentas portar un programa que escribiste en Delphi 6, hace 10 años, a un Delphi actual, el mayor problema no te lo encuentras en los cambios del lenguaje, sino en los componentes que utilizaste. ¿ De donde sacas esos FastReports 2 o QuantumGrid 3, etc. ... ?, esas versiones no están disponibles para las versiones actuales de Delphi, además tampoco querrías utilizarlas (¿ para que te actualizas entonces ?), vas a tener que utilizar las versiones actuales de esos componentes de terceros. Y los fabricantes de componentes si que no se preocupan mucho por la compatibilidad hacia atrás. Un report FastReports 2 no tiene nada que ver con uno FastReports 4, incluso el formato de archivo ha cambiado. Una grid QuantumGrid 3 ha cambiado totalmente sus propiedades y estructura de clases respecto a las grids QuantumGrid 6. El trabajo de portar ese código antiguo a una versión actual de Delphi es enorme, por lo que ya no te viene de ahí si encima tienes que adaptar un poco también el código Pascal.

Saludos.

[Delphius]

Hola Delphius.


No coincido contigo aquí. Estamos hablando siempre solo de las clases formularios (y frames, ...). Solo en estas clases (las que ahora llevan archivo .dfm) se van a inicializar algunas de sus propiedades.

¿ Pero que problema hay en eso ?, yo no lo veo contra norma, ni definiendo un objeto. Muchas clases en su código de creación se inicializan y dan valores por defecto a sus atributos, ... Esto es lo que hacemos en mi propuesta en el evento OnCreate, inicializamos los formularios de esta clase, dándole sus valores por defecto.

Después ya está en manos de tu código el cambiar esos atributos para hacer que una instancia determinada sirva a las necesidades concretas de un momento determinado.

Hola Marc,
Yo entiendo que una cosa es inicializar y otra diferente ya es establecer las propiedades definitivas y que nunca cambiarás. En el caso de un form, frames y sus controles la mayoría de las veces no se cambiarán los valores. Bajo esa premisa te podría aceptar entonces la posibilidad de "inicializar" las propiedades en el OnCreate como comentas.

Pero luego resulta ser si uno está interesado en crear nuevos forms y frames. Todos esos tendrán lo mismos valores. Como comentas, la solución pasará por hacer la correcta asignación por código.

El asunto es que eso lleva a más código.... cuando son pocos forms el lio no es demasiado, pero en los aplicativos de muchos forms es demasiado confuso.

En el dfm solo quedan los valores específicos atribuidos, y distinto al default, a un form, frame y sus controles/componentes. Los valores por defecto son asignados por el compilador de forma totalmente automática cuando se crean. Me parece a mi que por unos pocos cambios y el ahorrarse unos pocos kbs de un .dfm no vale la pena llevar esto al código.

No sé en que se diferencia esto a cualquier otra clase de Delphi (que también se inicializan con valores predeterminados en su creación).

Creo que me explicado antes. Una cosa es la inicilización, otra el valor por defecto y por último la asignación que uno le indica.
Cuando se crea una clase se inicializan unos atributos, luego se procede con la lectura de los valores por defecto y/o de los valores asignados en el dfm (si se trata de una clase TComponent que es la que ofrece la posibilidad de streaming).
Nada te impide hacer lo que comentas Marc. No lo discuto, en ese sentido se parece a cualquier otra clase.

El punto es que la inicialización sólo es una etapa previa y no necesariamente está hecha para asignar los valores reales que necesitas. Es a efectos de instanciación.

No me gustaría tener que estar redeclarando nuevas asignaciones a atributos que ya se hacen de forma simple cada vez que quiera reutilizar un form.

Esto creo que ya lo hablamos hace poco, sinceramente las necesidades del compilador me tienen sin cuidado. No entiendo esta mala costumbre de Delphi de obligarnos a escribir de más solo para que el compilador tenga la información mascada.

Marc, a veces pienso que tu ya lo vez a eso como por vagancia. 
Se supone que uno debe tener el control sobre el compilador e indicarle las cosas, el compilador podrá ser muy inteligente y eficiente pero responde a tus órdenes.

Si el compilador tuviera la capacidad de decidir por demás sobre ti, te obligaría a ti a ser más duro y estar añadiendo más clausulas cuando no quieras que haga lo que hace por "defecto".

El compilador no lo usaría nunca como argumento.

El punto es que no lo usé al compilador como argumento, sino que fue un simple comentario del porqué necesitaba que una clase esté en interface para poder determinar su visibilidad.

En ese punto es donde yo proponía que eso es redundante. Porque el compilador hace primeramente una comprobación sobre la clase y luego sobre la visibilidad de sus atributos, propiedades y métodos. Es allí donde yo sugiero que sería más práctico y efectivo que las clases estén en una sección implementation. Luego, si dicha clase debe ser pública que se añada a la sección interface con una hipotética cláusula Classes.

Creo que tu me entendiste mal. No defendí en esa ocasión al compilador, sino una crítica... lo mio fue sólo un comentario a fin de aclarar algo.

Me niego a trabajar de más para ponerle las cosas más fáciles al compilador. Podemos discutir sobre legibilidad del código, funcionalidad, elegancia, etc. ... pero sobre el compilador no, el compilador que espabile un poco, es una herramienta a nuestro servicio, no somos los programadores quienes estamos al servicio del compilador (como cuando nos obliga a marcarle si un método es dinámico o virtual), si esa información la puede detectar él, no deberían obligarnos a declararla explícitamente.

Eso ya lo discutimos antes. Repito... tomaste mis palabras sobre el compilador como si fuera una defensa cuando en esta ocasión fue un simple comentario aclaratorio.

Aún sigo defiendiendo que dejar al compilador que haga demasiado por nosotros nos llevará a que actuemos como meras personas que sus códigos se llenarán de excepciones para indicarle que no interprete las cosas como por defecto. Se supone que nosotros indicamos lo que debe ser la norma, y no simplemente él.

Acompaño tu sentir en que el compilador debe sudar un poco más y hacer las cosas de mejor modo y facilitarnos el trabajo. Pero llevarlo hacia lo que tu propones... es perder el control sobre él y en principal medida sobre nuestros trabajos.

Eso mismo ha comentado egostar. Le he sugerido una sintaxis explícita para public y private en la Unit, con un ejemplo.

He visto tu ejemplo. Da lo mismo si la sección se llama interface/implementation o public/private.
Es medio confuso ya que la cláusula public y private las empleamos dentro de una clase. Pero no es nada grave.

Ahora tengo una pregunta, según tu ejemplo, ¿en donde pondrías la clase?

Delphius, en este ejemplo MiClase no es una clase privada, esta clase se puede utilizar por cualquier módulo que enlace esa Unit. Por tanto la clase es pública (hasta donde yo lo entiendo).

Pues te digo que te equivocas. Esa clase SI es privada, sólo se puede usar dentro de esa unit. Cualquier otra unidad que tenga en uses la unidad no podrá ver la clase MiClase.

Te invito a hacer la prueba. Es más, no es posible verla aún haciendo esto:

delphi

Unidad.MiClase;

Y respecto a una clase fachada con métodos y atributos privados internos donde delega y reparte la funcionalidad, eso funciona exactamente igual con mi sugerencia de integrar declaración e implementación.

Creo que no me entendiste nada bien. Quisiera preguntarte si tienes conocimiento sobre patrones.

Una Fachada es una clase con visibilidad pública. No interesa como está diseñada, si tiene atributos, métodos y propiedades privados, protegidos, y/o públicos.
El punto es que la clase Fachada actúa de enlace entre la clase cliente y un conjunto de clases privadas que al cliente no le interesa.

El uso de una Fachada es útil para ocultar una compleja relación de clases y ofrecer un único punto de acceso para el cliente. De este modo el cliente no se ve fuertemente acoplado con esta red de clases, actúa y se comunica únicamente con la Fachada.

Nuevamente te invito a leer sobre el patrón Fachada.
Hablé sobre el patrón Fachada para dar un ejemplo de la diferencia entre clases privadas u públicas. Es uno de los motivos de mi propuesta de la sección Clasess. Si uno quiere que sus clases sean públicas la pone en la lista, de otro modo será interpretada como interna o privada y sólo podrá ser vista por el resto de las clases de la unidad.

La clases se mueven a la sección implementation o private (como en tu propuesta).

Lo siento, sigo sin ver ninguna diferencia entre la visibilidad de las declaraciones actuales en Delphi y las que se pueden conseguir integrando la declaración y la implementación.

Y sigo sin comprender el porqué debamos mezclar en la definición la implementación del código de los métodos.

Como en mi ejemplo, preferiría que esté la clase en implementation/private y tener el tradicional:

delphi

TMiClase = class
private
  procedure Foo;
end;
 
procedure TMiClase.Foo;
begin
 // aqui el código
end;

Es mucho más fácil de leer y entender.

Saludos,

[egostar]

Creo que aquí es donde diferimos de verdad. A mi no me importaría ver de vez en cuando una buena sacudida en el lenguaje, aunque pierdas completamente la compatibilidad hacia atrás.

NOTA: Sinceramente, ¿ cuan útil es la compatibilidad hacia atrás ?. Cuando intentas portar un programa que escribiste en Delphi 6, hace 10 años, a un Delphi actual, el mayor problema no te lo encuentras en los cambios del lenguaje, sino en los componentes que utilizaste. ¿ De donde sacas esos FastReports 2 o QuantumGrid 3, etc. ... ?, esas versiones no están disponibles para las versiones actuales de Delphi, además tampoco querrías utilizarlas (¿ para que te actualizas entonces ?), vas a tener que utilizar las versiones actuales de esos componentes de terceros. Y los fabricantes de componentes si que no se preocupan mucho por la compatibilidad hacia atrás. Un report FastReports 2 no tiene nada que ver con uno FastReports 4, incluso el formato de archivo ha cambiado. Una grid QuantumGrid 3 ha cambiado totalmente sus propiedades y estructura de clases respecto a las grids QuantumGrid 6. El trabajo de portar ese código antiguo a una versión actual de Delphi es enorme, por lo que ya no te viene de ahí si encima tienes que adaptar un poco también el código Pascal.

Bueno, en este punto yo difiero con muchos y tal vez esté remando contra corriente, pero una de las cuestiones que siempre intento mencionar cuando se tiene oportunidad es que la compatibilidad hacia atrás es inversamente proporcional a los componentes de terceros que utilices.

Yo me curo en salud utilizando componentes nativos, y al decir nativos incluyo los componentes de terceros que vienen incluidos en el paquete, yo he migrado mis desarrollos de Delphi4 a Delphi2006 sin problema y seguramente lo haría con Delphi XE (excepto algunos reportes hechos con QReport que en D2006 no quise cambiar, pero la mayoría de ellos ya están en Rave)

Salud OS

[Delphius]

Creo que ha estas alturas será mejor partir el hilo y moverlo a debate. 

¿Que opinan?

Saludos,

[egostar]

Creo que ha estas alturas será mejor partir el hilo y moverlo a debate. 

¿Que opinan?

Saludos,

Hace un rato que esperaba lo hiciera alguien

Salud OS

[Delphius]

Hace un rato que esperaba lo hiciera alguien

Salud OS

Pues que no me decido en donde cortarlo
Que está difícil separar en donde nos fuimos del tema, hasta donde estuvimos hablando de C es razonable... pero se pierde la idea para el debate.

Saludos,

[eduarcol]

Pienso que es mejor moverlo completo-

[Marc]

Hola Delphius.

Parece que nos van quedando menos puntos de fricción .

El asunto es que eso lleva a más código.... cuando son pocos forms el lio no es demasiado, pero en los aplicativos de muchos forms es demasiado confuso.

En el dfm solo quedan los valores específicos atribuidos, y distinto al default, a un form, frame y sus controles/componentes. Los valores por defecto son asignados por el compilador de forma totalmente automática cuando se crean. Me parece a mi que por unos pocos cambios y el ahorrarse unos pocos kbs de un .dfm no vale la pena llevar esto al código.

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.

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.

He visto tu ejemplo. Da lo mismo si la sección se llama interface/implementation o public/private.
Es medio confuso ya que la cláusula public y private las empleamos dentro de una clase. Pero no es nada grave.

Ahora tengo una pregunta, según tu ejemplo, ¿en donde pondrías la clase?

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.

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.

Delphius, en este ejemplo MiClase no es una clase privada, esta clase se puede utilizar por cualquier módulo que enlace esa Unit. Por tanto la clase es pública (hasta donde yo lo entiendo).

Pues te digo que te equivocas. Esa clase SI es privada, sólo se puede usar dentro de esa unit. Cualquier otra unidad que tenga en uses la unidad no podrá ver la clase MiClase.

Te invito a hacer la prueba. Es más, no es posible verla aún haciendo esto:

delphi

Unidad.MiClase;

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).

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.

Y respecto a una clase fachada con métodos y atributos privados internos donde delega y reparte la funcionalidad, eso funciona exactamente igual con mi sugerencia de integrar declaración e implementación.

Creo que no me entendiste nada bien. Quisiera preguntarte si tienes conocimiento sobre patrones.

Una Fachada es una clase con visibilidad pública. No interesa como está diseñada, si tiene atributos, métodos y propiedades privados, protegidos, y/o públicos.
El punto es que la clase Fachada actúa de enlace entre la clase cliente y un conjunto de clases privadas que al cliente no le interesa.

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).

En definitiva estamos hablando de lo mismo que en el párrafo anterior.

Y sigo sin comprender el porqué debamos mezclar en la definición la implementación del código de los métodos.

Como en mi ejemplo, preferiría que esté la clase en implementation/private y tener el tradicional:

delphi

TMiClase = class
private
  procedure Foo;
end;
 
procedure TMiClase.Foo;
begin
 // aqui el código
end;

Es mucho más fácil de leer y entender.

Es cuestión de gustos, a mi me parece más fácil de escribir y leer si solo tengo :

delphi

TMiClase = class
private
  procedure Foo;
  begin
    // aqui el código
  end;
end;

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.