Campaña para corregir el uso de 'With' en Object Pascal

[mamcx]

En python se usa asi:

Código PHP:

with open('file.txt', 'r') as f:
       f.read()
       d.write(...) 


Zero ambiguedad.

[[Al González]]

Empezado por mamcx

En python se usa asi:

Código PHP:

with open('file.txt', 'r') as f:
       f.read()
       d.write(...) 


Zero ambiguedad.

Entonces en el ejemplo de la imagen que subí hay -1 ambigüedad.

¿Apoyas la propuesta?

[Casimiro Noteví]

Interesante propuesta.
No soy partidario de eliminarlo, aunque no lo uso nunca porque puede ser peligroso y no queda claro el código. Sin embargo, con una serie de reglas como las que indicas, sí me parece bien que se mantenga.

[mamcx]

El problema es que esta propuesta, la escuchara el dueño de Delphi? Y de hacerlo, creara los medios para migrar el codigo?

Lo dudo.

No es que sea muy dificil ver que se puede arreglar en un lenguaje, es que es mas facil agregar que quitar, y ni siquiera en los open source se ve mucho que se animen a quitar.

[Casimiro Noteví]

Me ha parecido entender que se pretende modificar para que sea más seguro y no haya equívocos o ambiguedades en el código, ¿no es eso?

[[Al González]]

Empezado por Casimiro Notevi

Me ha parecido entender que se pretende modificar para que sea más seguro y no hay equívocos o ambiguedades en el código, ¿no es eso?

¡Correcto! Eso pretende esta propuesta.

[Casimiro Noteví]

Empezado por Al González

¡Correcto! Eso pretende esta propuesta.

Me apunto, aunque no se me ocurre cómo darle visibilidad

[[Al González]]

Empezado por mamcx

El problema es que esta propuesta, la escuchara el dueño de Delphi?

Eso depende de ti, de cómo emplees tu tiempo y energía. El mundo mejora conforme decimos vale y actuamos; empeora cuando sólo nos detenemos a mirar las dificultades.

[mamcx]

Empezado por Al González

Eso depende de ti, de cómo emplees tu tiempo y energía. El mundo mejora conforme decimos vale y actuamos; empeora cuando sólo nos detenemos a mirar las dificultades.

Entiendo que intentes ser optimista, pero con Delphi todo ha sido muy consistente por años.

Ahora bien, ve a los foros del dueño, haz la propuesta, habla con la gente dentro, si recibes el mas *minimo* de escucha te sigo encantado.

Y lo digo, porque eso es lo que he hecho antes. No hay como ser optimista cuando la *realidad* ha sido consistente.

Ademas, es un hecho que en la generalidad de los casos, no se recibe muy bien cambios en los lenguajes que impliquen romper codigo, mucho mas cuando aqui la comunidad delphi es MUY *reaciente* a cambiar.

Pero sabes que me encanta que me prueben equivocado, mas cuando eso resulta en que le vaya bien a Delphi.

P.D: Y apuesto que la misma respuesta la recibirias de FreePascal.

[[AgustinOrtu]]

A mi no me gusta el with en ninguna de sus formas, sabores y/o colores. En ningun lenguaje. Asi que de proponer algo, solamente se me ocurre matarlo; y si no lo matan, no usarlo. Asi de facil

Por mas que se implemente algo como lo de python, sigue teniendo el problema de que agrega un bloque mas al codigo, con un nivel de sangria adicional, el cual no hace para nada mas legible el codigo. Si el problema es que no gusta escribir "nombres largos de variables" se puede utilizar una fea tecnica que es crear una temporal con el nombre "corto"

Código Delphi [-]
procedure TFoo.Something;
var
  ds: TDataSet;
begin
  ds := Self.MyDataSet;

  ds.Close;
  ds.Open;
  ds.FieldByName('foo');
 // etc
end;

Aun asi, yo sigo pensando que las variables abreviadas siguen siendo malas (de ahi lo de feo) porque "ds" no me dice mucho. Es como cuando aprendemos a programar que no se porque motivo a las variables siempre las llamabamos: x, y, z, temp, aux, flag, etc..

Otra forma de atacar el problema es usar metodos encadenados, o interfaces fluidas; basicamente todos los metodos que soporta la interfaz devuelven el objeto al que se le envio el mensaje; osea, todo devuelve Self y le puedo seguir encadenando llamadas a metodos.

De esta forma se puede usar una coleccion asi:

Código Delphi [-]
procedure Test;
var
  Collection: Spring.Collections.IEnumerable;
begin
  Collection
    .Where(function(const Each: TMyClass): Boolean
       begin
         Result := Each.Enabled;
       end)
   .Sort(function(const Left, Right: TMyClass): Integer
       begin
         Result := Left.Index - Right.Index;
       end)
  .ForEach(procedure(const Each: TMyClass)
       begin
         WriteLn(Each.Name);
       end);
end;

[[AgustinOrtu]]

Empezado por mamcx

Entiendo que intentes ser optimista, pero con Delphi todo ha sido muy consistente por años.

Ademas, es un hecho que en la generalidad de los casos, no se recibe muy bien cambios en los lenguajes que impliquen romper codigo, mucho mas cuando aqui la comunidad delphi es MUY *reaciente* a cambiar.

No es del todo cierto, Mario. Embarcadero muchas veces ha dado como "excusa" el no querer hacer X o Z por justamente lo que comentas, no romper un moton de codigo que ya existe, cuando no se puede preservar la compatibilidad hacia atras.

Pero en muchos otros casos si han "obligado" a ciertos cambios que se han mantenido consistentes desde el dia #1.

Por ejemplo, los string en Delphi desde toda la vida fueron 1-based, soportan COW: simplemente al asignar un nuevo valor a un string, la RTL se encarga de todo. En realidad lo que terminamos teniendo es un string que internamente es "inmutable", pero se tiene cierta "sintaxis sugar" que permite tratarlos como mutables, sin tener que andar usando StringBuilders. Otros lenguajes matarian por poder hacer algo asi. Todo eso esta muy bien en Delphi, pero solo es "estable" en el compilador para Windows

Para los compiladores moviles, los string son 0-based, y aun no, pero en el futuro, podrian volverse "realmente" inmutables:

Immutable Strings: If you want to change a character inside an immutable string, you have to break two or more, and combine these portions, or use a TStringBuilder.

For example, the following common operation (indexing into a string and modifying the string) cannot be done with immutable strings:

Código Delphi [-]
 S[1] := 'A';

If you use a string operation such as this, the Delphi mobile compilers emit the warning W1068 Modifying strings in place may not be supported in the future (Delphi). At some point, this warning is to be replaced by an error; you can convert it into an error right now on the Hints and Warnings page in Project Options.

We Recommend Using TStringHelper to Handle Strings in Mobile and Desktop Apps

Eso cambia mucho el codigo que ya existe!!. Por ejemplo: Quien no ha usado la funcion System.Pos. Bien, esa funcion solo sirve para strings con indice 1-based; no sirve para las 0-based. Para solucionarlo, "solamente" debemos usar TStringHelper.IndexOf. En toda nuestra base de codigo.

No solamente pasa con Pos; lo mismo sucede con: Copy, Delete, Trim.. basicamente hay que reescribir el codigo que maneja strings.

En un principio, los compiladores para moviles soportaban el tipo UTF8String. Luego, no se en que version, lo sacaron. Ahora en la ultima, 10.1 Berlin, esta de nuevo.


Entonces, no quiero criticar porque las cosas cambian; para mejorar, hay que cambiar. Si se pierde cierta compatibilidad hacia atras, "lo lamento": no se puede pretender que el codigo que esta escrito en Delphi en el año 2000, funcione sin tocarle absolutamente nada en 2016; no se hasta que punto se puede decir que es una "feature" que el codigo tan legado funcione: es tiempo de refactorizar y mejorar el codigo legado para que use las caracteristicas mas nuevas. Sino, no tiene mucho sentido actualizar el compilador "porque si"

Lo que si es para criticar, es que Embarcadero se jacte de decir: "no queremos perder la compatibilidad hacia atras", y se ponga a jugar con los string (entre otras cosas) como lo ha estado haciendo

[[poliburro]]

Cuando me inicié en pascal y use With simplemente no me gustó así que a la fecha no lo uso. Es como el Goto, sigue existiendo en Delphi pero no por eso se usa y es más, no vale la pena mejorarlo.

Empezado por mamcx

Ahora bien, ve a los foros del dueño, haz la propuesta, habla con la gente dentro, si recibes el mas *minimo* de escucha te sigo encantado.

Exacto, aquí lo conveniente es llevar las propuestas a la casa del dueño, por que no hacerlo y gritar al vacío es lo mismo...