Declaración de procedimientos y funciones abstractos (interfaces)

afska commented 5 years ago

Hay un caso de uso que queremos tener que sería:

Código del docente:

program {
  ProcedimientoDelAlumno(Rojo)
  ProcedimientoDelAlumno(Rojo)
}

Código del alumno:

procedure ProcedimientoDelAlumno(color) {
  // hacer algo con `color`...
}

El código del docente, cuando se analiza solo, no compila porque ProcedimientoDelAlumno no está definido.

Tal vez podríamos tener un pragma o sintaxis para indicar procedimientos y funciones que deben ser implementadas, que no rompa en compilación sino en ejecución cuando no se definió aún.

Ejemplo:

Que:

/*@abstract@*/
procedure ProcedimientoDelAlumno(color) {}

program {
  ProcedimientoDelAlumno(Rojo)
  ProcedimientoDelAlumno(Rojo)
}

procedure ProcedimientoDelAlumno(color) {
  // código posta del alumno...
}

funcione bien, y que:

/*@abstract@*/
procedure ProcedimientoDelAlumno(color) {}

program {
  ProcedimientoDelAlumno(Rojo)
  ProcedimientoDelAlumno(Rojo)
}

compile bien, pero al ejecutar tire BOOM porque no se definió.

Qué opinan @fidel-ml @foones ?

fidel-ml commented 5 years ago

Funcionaría, creo. Lo único es que hay que modificar al intérprete... ¿Ves algún problema, Pablo? FF

fidel-ml commented 5 years ago

Lo único es que me gustaría que el nombre fuese otro, onda /@external@/ o /@future@/ o /@to-be-defined@/ o /@needed@/... La noción de abstract me parece menos clara en este caso.

Lo interesante de esta propuesta es que el docente puede documentar qué es lo que el alumno debe proveer, y distinguir procedimientos erróneamente escritos de los que hay que implementar a futuro. FF

On Tue, Feb 12, 2019, 08:57 Fidel <fidel@unq.edu.ar wrote:

Funcionaría, creo. Lo único es que hay que modificar al intérprete... ¿Ves algún problema, Pablo? FF

gobstones / gobstones-interpreter

Declaración de procedimientos y funciones abstractos (interfaces) #43