Más Bugs? El "Abogado del Diablo" de Embarcadero

[[AgustinOrtu]]

En este punto estoy de acuerdo con vos

Es una estupidez lo de los Scoped Enums

Basicamente, en VCL escribes esto:

Código Delphi [-]
  Align := alClient;
  MessageDlg('bla', mtInformation, [mbOk, mbCancel], 0);

En FMX no compila, ya que se traduce asi

Código Delphi [-]
  Align := TAlignLayout.Client;
  MessageDlg('bla', TMsgDlgType.mtWarning, [TMsgDlgBtn.mbYes, TMsgDlgBtn.mbNo], 0);

Y no podes cambiarlo, eso es porque FMX fue compilado con la directiva Scoped Enums en ON

El codigo es mas largo y molesto de escribir

[jhonalone]

Hola Agustín.
Tienes "más razón que un santo", (como se dice por aquí).
Me recuerda la tediosa notación de Java. ("System.out.Println()" o bien "java.awt.event.ActionEvent evento".
¡¡¡Con lo bonito y lo fácilmente legible que era el código Delphi!!! "PrintLn()" y ya. Añoranzas...
Ya podía Embarcadero haberse esforzado un poquito, y (respetando la notación de toda la vida) haber "traducido" internamente la notación a la hora de compilar el código.
Un saludo.

[[Al González]]

Si bien parece que hubo por ahí alguna pifia de parte de Embarcadero, les sugiero que se tomen muy en serio los unit scopes, los namespaces la erradicación del With (a menos que por fin sea blindado) y procuren evitar toda referencia en código que se preste a ambigüedad o genere duda de procedencia.

Los identificadores calificados es probablemente una de las mejores prácticas que debemos adoptar. El mundo ya no es pequeño, las bibliotecas son muchas y muy vastas, los nombres tienden a colisionar.

[[AgustinOrtu]]

Con el with estoy de acuerdo, sin pensarlo; la unica excepcion para el with es este caso: The Either Type en el cual comparto con Stefan

Pero con el tema de los Scoped Enum no. Y es que el problema esta en que en la VCL seguimos "de la manera vieja" y en FMX esta "la manera nueva" y esto genera mucha confusion. Yo creo que Embarcadero deberia haber hecho el mismo cambio en sus dos framework, no solamente en uno

Por otro lado, el tema "ambiguedad", no estoy de acuerdo

Código Delphi [-]
uses
  System.SysUtils,
  Unit1 in 'Unit1.pas';

type
  TNumeros = (Uno, Dos, Tres);

  // declarado en seccion interface de Unit1, sino obtendria un Identifier redeclared: 'Uno'
//  TPalabras = (Uno, Delphi);

var
  Numero: TNumeros;
  Palabra: TPalabras;
begin
  Numero := Uno; // TNumeros.Uno
  Numero := Dos; // TNumeros.Dos
  Palabra := Uno; // E2010 Incompatible types: 'TPalabras' and 'TNumeros'
  Readln;
end.

Este codigo no compila, lo cual es algo bueno

Si hay colisiones de enumerativos, o bien se usan calificadores completos, o bien se usa otro prefijo. Pero no se puede decir que hay posibilidad de codigo ambiguo como en el caso del with que ya todos sabemos que puede desencadenar en un desastre

[[Al González]]

https://twitter.com/algonzalez74/sta...35658950909953

https://twitter.com/algonzalez74/sta...36471987408896

Un saludo sin ánimo de debate.

[jhonalone]

Bueno.
No quería yo levantar tanta polémica.
Pero estoy de acuerdo con Al, el código debe ser lo más fácilmente inteligible por los humanos, aunque por parte de la máquina tenga que esforzarse un poquito más por traducir las expresiones.
Saludos.

[[AgustinOrtu]]

Yo me sigo inclinando por la variante #1 de las 2 que escribi en el mensaje #2

Soy un fanatico de escribir poco codigo, es decir, esto no me gusta para nada:

Código Delphi [-]
  Writeln(ExtractFileName(ParamStr(0))); // 
  Writeln(AppBinName); // 

De hecho, el escribir las distintas versiones de MessageDlg me terminaron resultando muy molestas, ademas no tienen opcion para enviar argumentos para aplicar Format (como si existe una ShowMessageFmt)

Y por eso me escribi unos propios metodos que invocan a MessageDlg pero apenas envio parametros:

Código Delphi [-]
  InfoMsg(const AMessage: string); // MessageDlg(AMessage, mtInformation, [mbOk], 0);
  InfoMsgFmt(const AMessage: string; Args: array of const); // MessageDlg(Format(AMessage, Args), mtInformation, [mbOk], 0);
  PromptMsg(const AMessage: string): Boolean; // MessageDlg(AMessage, mtConfirmation, mbOkCancel, 0);
  ...

No es mas facil y rapido de escribir, amigable, legible, el propio metodo intenta indicar su proposito (InfoMsg esta claro que va a mostrar un cuadro de dialogo con informacion, les dejo para adivinar: que haran los metodos ErrorMsg y WarningMsg? )

No entiendo porque el uso de enumerativos sin calificadores completos pueda llevar a ambiguedad, Al si puedes poner un ejemplo te lo agradeceria, porque no me doy cuenta