nscarcella
commented
4 years ago Bueno, paso en limpio las notas de la última reunión de roadmap.
Establecimos 5 usos para el initialize:
a. Ejecutar validaciones y preservar invariantes: Es discutible si el initialize es EL lugar para hacer esto, pero hoy Wollok no tiene una opción mejor (sobre todo si sacamos los constructores) porque los parametros del new no pasan por los setters. Personalmente, este es tal vez el único uso que realmente me importa del initialize, porque ya me saltaron varias veces alumnos con la duda de dónde validar cuando vemos excepciones.
Ej: Validar que el saldo de un cliente (parámetro de construcción) no sea negativo.
b. Lógica de inicialización: Evaluar cualquier regla de negocio que requiera evaluarse al inicio de la vida del objeto. Es importante para esto considerar en que estado de "correctitud" se encuentra el objeto cuando se ejecuta esta lógica: ¿Puede asumir que tiene todas sus variables Inicializadas? ¿Puede asumir que al menos tiene las que hereda? etc.
Este uso es bastante importante en mi opinión, porque yo hago mucho foco en que un objeto tiene estar siempre en un estado consistente y que eso hay que mantenerlo o fallar. Supongo que puedo evitar dar ejemplos donde esto sea un problema, pero creo que, por completitud, Wollok debería dejarme hacer esto.
Ej: Mantener una referencia cruzada entre alumnos y curso, haciendo que el alumno le mande un mensaje al curso que recibió en la construcción para que lo agregue a sus hijos.
c. Restringir los parámetros de instanciación: El razonamiento es que, si el initialize va a pisar lo que yo pase como parámetro a un new, podría resultar confuso. Con lo cual, podría ser deseable que los campos seteados en el initialize no sean obligatorios para el new.
Ej: Si mi initialize setea la energía máxima de una golondrina independientemente de lo que me pases en el constructor quisiera ver un mensaje de alerta cuando haga new Golondrina(energíaMáxima = 10) o que directamente no me dejes pasarle eso, porque va a ser ignorado. También querría que me deje hacer new Golondrina() (asumiendo que no hay otros campos sin defaults), porque obligarme a pasarle un valor que va a ignorar es rarísimo.
d. Inicializar atributo que depende de otro: Básicamente, si una clase tiene un atributo a que espera recibir en el new, y otro atributo b que se calcula a partir de a tiene que haber algún lugar dónde esto pueda resolverse. El initialize podría ser este lugar.
Acá yo haría la mención de que algunas constantes de Wollok aspiran (entiendo yo) a usar sólo expresiones puras y eso es lo que permite que su inicialización sea lazy. Por eso este test, por ejemplo, funciona:
const a = b
const b = 1
test "inicialización lazy" { assert.equals(a, 1) }Acá hay unos tests que agregamos comentados en su momento que cubren algunas expectativas de lazyness en la inicialización.
Menciono esto porque la inicialización lazy es necesaria para tener objetos inmutables que se referencien mutuamente (super común) y entiendo que este es un tema sobre el que se busca avanzar.
Obviamente, de existir este feature, no habría ninguna necesidad de recurrir al initialize para definir un campo a partir de otro y podríamos directamente hacerlo inline (mucho más cómodo, en mi opinión).
Ej: La energía de una golondrina se inicializa en su energía máxima.
e. Reformular un valor que llega: La instanciación con parámetros nombrados tiene la limitación de que sólo recibe cosas que sean atributos. Esto implica que cualquier parámetro que no sea exactamente el valor final para un atributo es contramano y, a veces te obliga a hacer chanchadas para poder recibir un valor que querés usar para inicializarte pero no querés exponer. Esto es especialmente choto con constantes porque, de última, con una variable podés pisar el valor original con el valor procesado, pero eso no lo podés hacer con una constante, salvo que desactives la constancia de las constantes durante el initialize (cosa que a mi me parece super turbio).
Ej: Quiero construir un Guerrero con una fuerza (constante) que tiene que ser un número >=1. Si recibo un número menor quiero convertirlo en 1. Sin constructores, hoy tengo que hacer que la fuerza sea una variable o agregar un atributo fuerzaInicial para que me pasen y luego no usarlo nunca más.
También me gustaría mencionar un par de otras inquietudes que surgieron:
-
Hubo preocupación por si se debería poder controlar el orden en el que se llaman los initialize de la jerarquía. Yo creo que es mejor mantener un orden fijo y, si querés hacer algo elaborado onda template o lo que fuera, simplemente delegues en un mensaje y hagas el super ahí.
-
A mi me preocupa no poder definir una constante que no sea seteable en el
new, pero no creo que el initialize sea la mejor forma de conseguir eso, así que prefiero sacarlo de la discusión y hablarlo en otra instancia. -
@npasserini planteó que estaría bueno ser cuidadosos con los casos que elegimos para guíar esta decisión y que, si la implementación final termina admitiendo algún workaround turbio podría ser mejor no mostrarlo en la documentación para que no parezca que se incentiva esa práctica (estoy parafraseando y espero haber entendido la idea, pero seguro Nico puede plantearlo mejor).
-
No hay que olvidarse que para construcciones complejas siempre se puede recurrir a singletons que implementen patrones creacionales.
Paso entonces a contar la propuesta que terminamos hilando al final y agrego otra un poco más volada que se me ocurrió durante la reunión y a Nico pareció interesarle. En todos los casos voy a contarlo usando la sintáxis de linearización de 3.0 que discutimos acá.
Propuesta 1: initialize como método ordinario
Esta es la propuesta más simple de todas las que manejamos y, básicamente, propone descartar cualquier trato especial para el initialize y dejarlo como un método más, sin parámetros.
En esta variante, el new no considera al initialize en absoluto para decidir qué cosas son o no parámetros obligatorios (con lo cual se mantiene la idea de que cualquier parámetro que no tenga un default o sea pasado en la linearización de supertipos tiene que ser provisto en el new). Esto exime al initialize de la responsabilidad de "llenar huecos" y garantiza que el objeto ya tiene todos sus atributos (heredados o no) en algún valor default o parametrizado al momento de evaluarse, lo cual da cierto grado de seguridad de que podés enviar mensajes sin que todo explote. Al mismo tiempo evita tener que deducir si una variable se setea a través de un setter (que yo digo que es imposible de hacer sound).
El initialize se enviaría automáticamente (como pasa ahora) luego de la instanciación, garantizando que siempre que haces new obtenés un objeto inicializado. El orden de llamado de los initialize de la jerarquía está sujeto a las mismas reglas de overrideo y super que cualqueir otro método: requiriendo el uso de override para pisar el mensaje (que ya tiene una implementación vacía en Object) y quedando el llamado a super() como responsabilidad del programador.
A continuación cuento cómo queda cada uno de los usos mencionados más arriba con esta variante:
a. Ejecutar validaciones y preservar invariantes: El caso queda cubierto perfecto. Para cuando el initialize se llama ya se tienen todos los atributos seteados y se puede validar o ajustar lo que sea necesario.
// Validar que el saldo de un cliente (parámetro de construcción) no sea negativo.
class Persona {
const nombre
override method initialize() {
super() // No hace falta realmente llamar a super porque en Object no hace nada, pero es buena práctica
if(nombre.isEmpty()) self.error("El nombre está vacío")
}
}
class Cliente inherits Persona {
var saldo = 0
override method initialize() {
if(saldo < 0) self.error("El saldo no puede ser negativo")
super() // Puedo llamar a super en cualquier punto
}
}
...
new Cliente() // ERROR! Hay que pasarle un nombre
new Cliente(nombre = "Diego") // OK! Pasan las validaciones y saldo defaultea a 0
new Cliente(nombre = "Jose", saldo = 100) // OK! Pasan las validaciones y saldo queda en 100
new Cliente(nombre = "") // OK! Las validaciones fallan y el objeto nunca llega nuestras manosb. Lógica de inicialización: Idem (a). Todo piola.
// Mantener una referencia cruzada entre alumnos y curso, haciendo que el alumno le mande un mensaje al curso que recibió en la construcción para que lo agregue a sus hijos.
class Curso {
const alumnos = []
method inscribir(alumno) { alumnos.add(alumno) }
}
class Alumno {
const curso
override method initialize() {
super()
curso.inscribir(self)
}
}
...
const curso = new Curso()
new Alumno(curso = curso) // OK! El alumno queda asociado al curso y viceversa.c. Restringir los parámetros de instanciación: En esta variante el initialize no se considera para decidir los parámetros de instanciación ni puede usarse para setear constantes.
// Energía máxima de una golondrina
class Golondrina {
const energíaMáxima
override method initialize() {
super()
// energíaMáxima = 100 // ERROR! Las constantes no se pueden pisar. De última convertila en variable.
}
}
new Golondrina(energíaMáxima = 100) // OK!
new Golondrina() // ERROR! Hay que pasar el máximo, no puede setearse en ningún otro lugar.d. Inicializar atributo que depende de otro: Esta variante no sirve para esto y requiere que la inicialización de atributos sea lazy o se ponga un placeholder (sólo sirve para variables).
// La energía de una golondrina se inicializa en su energía máxima.
class Golondrina {
var otraEnergía = energíaMáxima // inicialización lazy
const energíaMáxima
var energía
override method initialize() {
super()
energía = energíaMáxima // OK! Esto vale porque energía es una variable, no una constante, pero sería mejor hacerlo inline.
}
}
new Golondrina(energíaMáxima = 100) // ERROR! Hay que pasar energía, no importa que se setee en el initialize. Por eso hubiera sido mejor la variante inline o ponerle un default.
new Golondrina(energíaMáxima = 100, energía = 100) // OK! No necesito pasar otraEnergía.e. Reformular un valor que llega: Esta variante no sirve para esto y requiere un workaround.
// construir un Guerrero con una fuerza (constante) que tiene que ser un número >=1. Si recibo un número menor quiero convertirlo en 1.
class Guerrero {
const fuerza
var velocidad
const inteligenciaSugerida // Workaround turbio: Pongo esta const para que me la pasen por parámetro, pero sólo la uso para Inicializar
const inteligencia = inteligenciaSugerida.max(1)
override method initialize() {
super()
// fuerza = fuerza.max(1) // ERROR! No puedo pisar const
velocidad = velocidad.max(1) // OK! usé un var para velocidad en lugar de una const
}
}
new Guerrero(fuerza = -1, velocidad = -1, inteligenciaSugerida = -1) // OK! fuerza, velocidad e inteligencia quedan en 1
new Guerrero(fuerza = -1, velocidad = -1, inteligenciaSugerida = -1, inteligencia = 0) // OK! Me cagaste el workaround...Mi opinión es que esta solución es super simple y suficientemente buena. Todos los casos que no cubre son más bien raros y tienen workarounds simples.
Además, al ser un método, nos evita introducir un concepto extra y mantiene simples los conceptos de new y const.
Para un lenguaje productivo podría no alcanzarme, pero para Wollok creo que va como trompada.
Propuesta 2: initialize como bloque parametrizado (o constructor++)
Quiero hacer el disclaimer de que esta variante me la saqué del culo y la estoy tocando como sale.
La idea era tratar de presentar una alternativa menos simple pero más poderosa que cubra todos los casos que la otra alternativa deja medio afuera.
Básicamente, en esta variante el initialize es un bloque que tiene parámetros nombrados.
El new espera recibir todos los atributos que no tengan default o sean pisados por una asignación en el initialize y todos los parámetros del initialize.
El initialize se ejecuta después de que los defaults y el pasaje de parametros tuvo lugar y tiene todos esos valores disponibles.
El initialize no es un método y no puede (ni necesita) llamar a super. Los parametros para el initialize del supertipo se pasan igual que en la otra variante: en el new o la linearización.
El orden de evaluación es de arriba para abajo en la jerarquía, cómo es en C# o JavaScript, sólo que sin obligarte a escribirlo vos.
Esto garantiza que el objeto siempre recibe los atributos de sus supertipos consistentes y listos para usar.
Cualquier template loco que quieran hacer se puede hacer llamando a un mensaje y poniendo el super ahí.
Así quedarían los usos:
a. Ejecutar validaciones y preservar invariantes: Funciona igual que la Propuesta 1.
// Validar que el saldo de un cliente (parámetro de construcción) no sea negativo.
class Persona {
const nombre
initialize() {
if(nombre.isEmpty()) self.error("El nombre está vacío")
}
}
class Cliente inherits Persona {
var saldo = 0
initialize() {
// Cualquier referencia a 'nombre' puede hacerse normalmente. Si llegaste acá nombre está seteado y cumple las espectativas del supertipo.
if(saldo < 0) self.error("El saldo no puede ser negativo")
}
}
...
new Cliente() // ERROR! Hay que pasarle un nombre
new Cliente(nombre = "Diego") // OK! Pasan las validaciones y saldo defaultea a 0
new Cliente(nombre = "Jose", saldo = 100) // OK! Pasan las validaciones y saldo queda en 100
new Cliente(nombre = "") // OK! Las validaciones fallan y el objeto nunca llega nuestras manosb. Lógica de inicialización: Mismas capacidades que la Propuesta 1.
// Mantener una referencia cruzada entre alumnos y curso, haciendo que el alumno le mande un mensaje al curso que recibió en la construcción para que lo agregue a sus hijos.
class Curso {
const alumnos = []
method inscribir(alumno) { alumnos.add(alumno) }
}
class Alumno {
const curso
initialize() {
curso.inscribir(self)
}
}
...
const curso = new Curso()
new Alumno(curso = curso) // OK! El alumno queda asociado al curso y viceversa.c. Restringir los parámetros de instanciación: Tanto variables como constantes (incluyendo las heredadas) pueden ser inicializadas (pero no sobrescritas si son const) en el initialize, similar a lo que hacen lenguajes como TypeScript y Kotlin. Esto vuelve el concepto de constante un poco más complejo a cambio de dar más control en su inicialización.
// Energía máxima de una golondrina
class Golondrina {
const energíaMáxima
initialize() {
energíaMáxima = 100 // OK!
// energíaMáxima = energíaMáxima + 1 // ERROR! no se puede sobreescribir una const
}
}
new Golondrina(energíaMáxima = 100) // ERROR! energíaMáxima ya está inicializada en el initialize
new Golondrina() // OK!d. Inicializar atributo que depende de otro: Similar a la propuesta 1, pero depende menos de tener lazyness.
// La energía de una golondrina se inicializa en su energía máxima.
class Golondrina {
var otraEnergía = energíaMáxima // inicialización lazy
const energíaMáxima
var energía
override method initialize() {
energía = energíaMáxima // OK!
}
}
new Golondrina(energíaMáxima = 100) // OK! No hace falta (y de hecho, no puedo) pasar energía.
new Golondrina(energíaMáxima = 100, energía = 100) // ERROR! No puedo pasar energía
new Golondrina(energíaMáxima = 100, otraEnergía = 100) // OK! Si tenemos lazyness podés defaultear otraEnergía al máximo y aun así pisarla.e. Reformular un valor que llega: Este es el punto donde esta propuesta es mejor la 1. Teniendo parámetros en el initialize que no son atributos podés pasar falopa de inicialización sin tener que agregarsela a interfaz del objeto.
// construir un Guerrero con una fuerza (constante) que tiene que ser un número >=1. Si recibo un número menor quiero convertirlo en 1.
class Guerrero {
const fuerza
const inteligencia = 0
initialize(fuerzaSugerida) {
fuerza = fuerzaSugerida.max(1) // OK!
}
method fuerzaSugerida() {
return fuerzaSugerida // ERROR! fuerzaSugerida no existe
}
}
new Guerrero(fuerzaSugerida = -1, inteligencia = 10) // OK! fuerza queda en 1
new Guerrero(fuerzaSugerida = -1, fuerza = -1, inteligencia = 10) // ERROR! No le podés pasar fuerza porque se setea en el initializeYo creo que es indiscutible que esta solución es más poderosa que la (1), peeeeero la pregunta es si ese poder vale la pena. Para un lenguaje productivo estoy seguro que me gusta la posibilidad de recibir no-atributos en la construcción. Eso es también más parecido a un constructor y otras cosas que hay en el mercado. Pensando en un aula no estoy tan seguro... Yo el initialize sólo lo uso para el caso (a) en clase, con lo cual un método me alcanza y sobra. Por otro lado, la complejidad de usar la propuesta 2 es puramente optativa: si no querés contar los parámetros podés sólo no hacerlo y se parece mucho a la opción 1. Pero bueno, no sé... Me gustaría saber que opinan ustedes. A mi cualquiera de estas dos variantes me harían feliz. En particular quiero evitar la "desactivación" de validaciones, quisiera que todas las reglas sean lo más generales y claras posible.
npasserini
PalumboN
fdodino
lspigariol
asanzo
LINK AL DOCUMENTO CON LA VERSIÓN FINAL: https://docs.google.com/document/d/1DnRnRKnO3IDQya3NZJqj-U-6ICrAhgUhaqpuZfGjRFk/edit#
Tanto para
varcomoconst(sino forzar la inicialización a= null).