Open nscarcella opened 3 years ago
fdodino
commented
3 years ago Paseando un poco por los issues, entiendo que por el momento ganó la idea de no sacar el override porque hay muchas validaciones que se vuelven más simples y que causan más dolor cuando tenemos el override vs. algo que directamente se puede autocompletar.
nscarcella
commented
3 years ago Ampliando un poco este comentario, en la última reunión stalleamos todos los cambios de keywords y asuntos relacionados con abstract, override y similares. Capaz dejando decantar un poco surge alguna propuesta más compradora.
El tema con las validaciones no me queda claro que se hagan más dificiles (porque si un método está overrideando otro es algo que se puede detectar sin ninguna keyword) pero se pierde dato de si el usuario está overrideando apropósito o si, por el contrario, intentaba overridear algo y no lo está haciendo realmente.
El argumento sobre esto a favor de borrar el override es que es realmente muy raro que en una jerarquía chiquita de un programa a nivel universitario overridees "por accidente" y buscar overridear algo y equivocarte el nombre no es distinto de cuando te pasa buscando que algo sea polimórfico con otra cosa. También se hizo hincapié en que el override se convierte rapidamente en una respusta mecánica más que un indicador de intención: El pibe pone override cuando el IDE se lo pide y pasa con tan poca frecuencia que se olvida cómo hacerlo y trae problemas.
Esto es en gran medida, creo yo, porque queremos hablar de métodos mucho antes de herencia y el override queda contramano. Eso nos lleva a poner excepciones de cuándo hace falta y cuándo no y eventualmente eso lleva a que sea un concepto más complejo que no queda claro cuándo hay que usarlo o porqué. El ejemplo más frecuente de esto es el initialize.
Yo estoy tentando de explorar formas alternativas de encarar las inquietudes a las que atiende el override. Ahora que vamos a meternos en terrenos nuevos con IDEs y herramientas, capaz podríamos tratar de plasmar esta información sin que sea parte de la sintáxis.
Derivado de discusiones acá: https://github.com/uqbar-project/wollok/issues/1861
Decidimos crear un ticket aparte para discutir esto.
Nos debemos una discusión más profunda sobre el tema, pero en general la gente parece inclinada por sacar la palabra clave, pero les da miedito que se use en algún lado (por ejemplo, el typesystem).
Los puntos a favor de quitarlo en general giran alrededor de que es verboso y ya existen excepciones fuleras (como el initialize). Los puntos a favor de mantenerlo es la protección contra la posibilidad de equivocarte al redefinir un método o protegerte de un cambio futuro en una superclase.