Declaración opcional de interfaces?

[mmatos]

Tiro esto para ver qué opinan: hoy en día se habla de la idea de interfaz en clase, tal vez no desde la primera vez que aparece la idea de polimorfismo, pero sí más adelante y se hace una distinción eventualmente entre clase abstracta e interfaz.

Las interfaces no son programables en Wollok. Definitivamente no querría forzar a que se tenga que declarar una interfaz para poder usar polimórficamente los objetos, o sea, querría mantener el duck typing que tenemos. Pero no podría ganarse algo de la posibilidad de programar una interfaz y explicitar cuando una clase implementa esa interfaz?

Cuando se define una clase abstracta que no aporta absolutamente nada más que las firmas de los métodos que las subclases deberían implementar, esa clase abstracta aparece en el diagrama estático, y cuando heredás de esa clase el IDE tiene la posibilidad de marcar cuáles son los métodos que necesitás definir. Yo creo que esas cosas, si bien son menos relevantes que poder usar polimórficamente dos objetos sin burocracia, están buenas para tener.

Hoy en día encuentro que en algunos TPs hay grupos que declaran clases abstractas para abstracciones donde claramente querían una interfaz y me pregunto si es por un tema conceptual o porque querían tener la posibilidad de declarar una interfaz y eso fue lo más cercano que tenían.

Disclaimer: todo esto lo digo en un contexto en el cual no se usan mixins porque no es un tema que se de en la materia. Por ahí se puede resolver usando mixins cuando lo que querías era una interfaz, que es lo que se hace en Scala por ejemplo, donde sí necesitás explicitar un tipo común cuando usás tipado nominal (o sea, la mayoría del tiempo).

[lspigariol]

El lun., 5 nov. 2018 a las 11:52, Mariana (notifications@github.com) escribió:

Tiro esto para ver qué opinan: hoy en día se habla de la idea de interfaz en clase, tal vez no desde la primera vez que aparece la idea de polimorfismo, pero sí más adelante y se hace una distinción eventualmente entre clase abstracta e interfaz.

Las interfaces no son programables en Wollok. Definitivamente no querría forzar a que se tenga que declarar una interfaz para poder usar polimórficamente los objetos, o sea, querría mantener el duck typing que tenemos. Pero no podría ganarse algo de la posibilidad de programar una interfaz y explicitar cuando una clase implementa esa interfaz?

Cuando se define una clase abstracta que no aporta absolutamente nada más que las firmas de los métodos que las subclases deberían implementar, esa clase abstracta aparece en el diagrama estático, y cuando heredás de esa clase el IDE tiene la posibilidad de marcar cuáles son los métodos que necesitás definir. Yo creo que esas cosas, si bien son menos relevantes que poder usar polimórficamente dos objetos sin burocracia, están buenas para tener.

Hoy en día encuentro que en algunos TPs hay grupos que declaran clases abstractas para abstracciones donde claramente querían una interfaz y me pregunto si es por un tema conceptual o porque querían tener la posibilidad de declarar una interfaz y eso fue lo más cercano que tenían.

Disclaimer: todo esto lo digo en un contexto en el cual no se usan mixins porque no es un tema que se de en la materia. Por ahí se puede resolver usando mixins cuando lo que querías era una interfaz, que es lo que se hace en Scala por ejemplo, donde sí necesitás explicitar un tipo común cuando usás tipado nominal (o sea, la mayoría del tiempo).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1556, or mute the thread https://github.com/notifications/unsubscribe-auth/ALMbm5p2B29Zpwpn5KUQyVRE8gRNjpcFks5usFCegaJpZM4YOmJt .

[javierfernandes]

A mí siempre me pareció interesante ese punto. Incluso es una de las cosas que extraño en JS. Muchas veces uno termina igual documentando las firmas o contratos como un simple comentario. En JS lo que hago es escribir la definición del tipo con sintaxis de TypeScript.

No se. tal vez se pueda pensar en una interfaz sin inmiscuirse en temas de tipado o type-system, pero me parece que pierden gran parte del beneficio. Porque también explícita o implícitamente el contrato involucra tipos. Aunque no tengas checkeos, vos definís una interfaz pensando en los mensajes y la formas de los parámetros y valor de retorno de estos.

Incluso cuando tenés un sistema de tipos superinteligente que infiere todo y funciona de lujo, lo más probable es que termine trabajando con tipos estructurales, y como bien decís te perdés la posibilidad de explicitar un concepto con un nombre.

En TS las interfaces son como bien decís opcionales si no me equivoco. O sea, si yo defino un método que espera como parámetro una interfaz A, si luego paso un objeto que entiende los mismos mensajes aunque no implemente la interfaz es compatible. 🤔 ahora me agarró la duda de si eso sólo pasaba con los type aliases 🤔 Lo cual me lleva a lo que iba. A mí me gustan mucho los type aliases en TS y en Scala para esto mismo. Capaz para funciones pero es lo mismo. A veces en lugar de String => String => Boolean prefiero un alias type StringComparator = String => String => Boolean Sin embargo es un feature opcional, si a otro programador le pinta no usar el type todo funciona igual. Para mí está buena esa idea de compatibilidad entre definiciones de tipos.

[lspigariol]

bien, en estos días me estuve preguntando lo mismo!

historicamente, en pdep nunca hablaba de interfaces ni de la necesidad de escribir codigo abstracto, es decir declaraciones que lo que aportan es obligar a que se redefinan. en el ultimo tiempo, al ver que en otros cursos se lo empezaba a dar como concepto, lo empece a nombrar, aunque muy sutilmente y dependiendo del curso. A veces, el tema surge al querer hacer los diagramas de clases. Con wollok, estando obligado a escribir métodos abstractos por ejemplo en un templete method, surge por primera vez esta necesidad de codigo "extra" para que "funcione".

En general, no me gusta la idea de escribir codigo que no aporta funcionalidad, pero por otro lado entiendo que aporta expresividad. En general, me gusta que wollok se diferencie de otros lenguajes y que haga aportes originales, pero a la vez quiero que ayude a entender lo que se usa en la industria.

Volviendo a la propuesta de Maiu,

• Esta bueno que haya interfaces, siempre y cuando sean opcionales. (es otro el espacio de discusion, pero prefiero que interfaces no sea tema de pdep)
• Con el mismo criterio, me gustaría que también sea opcional la definición de métodos abstractos
• Y asociado a esto ultimo, sería mas practico declarar la clase como abstracta.

En cualquier caso, nos debemos una charla para revisar como hacer diagramas sin superclases ni interfaces y como estandarizar gráficamente los WKO. En otras palabras, cuánto nos queremos diferenciar/asemejar al estandar UML.

El lun., 5 nov. 2018 a las 11:52, Mariana (notifications@github.com) escribió:

Tiro esto para ver qué opinan: hoy en día se habla de la idea de interfaz en clase, tal vez no desde la primera vez que aparece la idea de polimorfismo, pero sí más adelante y se hace una distinción eventualmente entre clase abstracta e interfaz.

Las interfaces no son programables en Wollok. Definitivamente no querría forzar a que se tenga que declarar una interfaz para poder usar polimórficamente los objetos, o sea, querría mantener el duck typing que tenemos. Pero no podría ganarse algo de la posibilidad de programar una interfaz y explicitar cuando una clase implementa esa interfaz?

Cuando se define una clase abstracta que no aporta absolutamente nada más que las firmas de los métodos que las subclases deberían implementar, esa clase abstracta aparece en el diagrama estático, y cuando heredás de esa clase el IDE tiene la posibilidad de marcar cuáles son los métodos que necesitás definir. Yo creo que esas cosas, si bien son menos relevantes que poder usar polimórficamente dos objetos sin burocracia, están buenas para tener.

Hoy en día encuentro que en algunos TPs hay grupos que declaran clases abstractas para abstracciones donde claramente querían una interfaz y me pregunto si es por un tema conceptual o porque querían tener la posibilidad de declarar una interfaz y eso fue lo más cercano que tenían.

Disclaimer: todo esto lo digo en un contexto en el cual no se usan mixins porque no es un tema que se de en la materia. Por ahí se puede resolver usando mixins cuando lo que querías era una interfaz, que es lo que se hace en Scala por ejemplo, donde sí necesitás explicitar un tipo común cuando usás tipado nominal (o sea, la mayoría del tiempo).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1556, or mute the thread https://github.com/notifications/unsubscribe-auth/ALMbm5p2B29Zpwpn5KUQyVRE8gRNjpcFks5usFCegaJpZM4YOmJt .