Re-pensar la API

[PalumboN]

Fijarse cómo se usa la VM en otros proyectos y ofrecer una mejor API.

CLI

• En este PR se movió lógica https://github.com/uqbar-project/wollok-ts-cli/pull/72

LSP

• Este archivo https://github.com/uqbar-project/wollok-lsp-ide/blob/master/server/src/utils/wollok.ts

Mobile

• Este archivo https://github.com/uqbar-project/wollok-mobile/blob/dev/src/utils/wollok-helpers.ts

[fdodino]

@PalumboN , creo que faltaría encarar solamente la parte Mobile. La parte de LSP que quedaba la empecé a mover en otro PR que va a salir, por ahí lo puedo renombrar usando este ticket.

[fdodino]

Respecto a la implementación de los helpers de Mobile:

• [x] allFields: ya existe en model
• [x] allMethods: ya existe en model
• [x] allVariables: hay que crearla. Plot twist: existía getAllVariables.

export function allVariables(node: Method | Test): List<Variable> {
    return node.sentences().filter(is('Variable'))
}

• [x] isNamedSingleton: hay que agregarlo y de paso usarlo en Evaluation.globalSingletons:

const globalSingletons = environment.descendants.filter((node: Node): node is Singleton => node.is(Singleton) && !!node.name)

• [x] methodLabel: el de Method devuelve el fully qualified name + la aridad. Yo propongo usar un fullLabel

export function methodLabel(method: Method): string {
    return `${method.name}(${method.parameters.map(_ => _.name).join(',')})`
}

• [x] literalClassFQN:

export function literalClassFQN(literal: Literal): Name {
    return `wollok.lang.${upperCaseFirst(typeof literal.value)}`
}

para mí se reemplaza por literalValueToClass en helpers

• [x] allScopedVariables: usa CodeContainer pero CodeContainer es un Test o Method, qué onda un Program?
• [x] containerOf es un método que habría que ver cómo los migramos porque hay un CodeContainer. No me termina de convencer, por ahora lo dejaría acá.
• [x] methodFQN: es el label que está implementado en la clase Method (Model) pero sin llamar a super. Lo que hice fue reemplazar la definición del label() de Method y le saqué la llamada a super.label porque mostraba el ObjectId del nodo, no había ningún test que lo probara y tampoco resultaba útil por fuera de ts. @PalumboN @nscarcella avísenme si esto puede romper algo.
• [x] methodByFQN: habría que migrarlo a helpers
• [x] entityMemberLabel: lo dejaría, no tengo contexto para ver por qué chequean si es método y por qué no se puede usar un label común. Cuando esté todo mergeado deberían poder hacer

return node.is(Method) ? node.label : node.name // sacarle ' al is

• [x] entityMemberFQN: lo mismo que el anterior, a mí me gustaría ver por qué fue necesario armar algo custom
• [x] isError: curioso que no hay ningún método, lo migraría a helpers (BaseProblem y Problem son interfaces, qué macana)
• [x] TestResult, TestRun, FinishedExecutionState, interpretTest: son helpers para ejecutar el test, dado que no se llama a wollok-ts-cli yo lo dejaría como está.
• [x] isNullExpression: en helpers hay dos lugares donde necesitaríamos tener esa abstracción, hay que migrarla. Lo que hice fue renombrarla a hasNullValue, y lo mismo renombré el isBooleanLiteral por hasBooleanValue para ser más consistentes con lo que queremos testear de la expresión.
• [x] executionFor: es un interesante método, hay que migrarlo: lo puse como función exportada en interpreter.
• [x] projectToJSON: lo migraría
• [x] isComplete: lo migré, y le puse 6 tests. Pero la verdad es que no pude replicar un caso en el que no me de true. Y siento que no tengo en claro cuál es el objetivo. Lo dejé.
• [x] isEmptyArgument: iba a decir de migrarlo pero no siento que el nombre tenga sentido en otro contexto al que lo están usando. Lo voy a inlinear dentro de isComplete.

Ahora estoy haciendo una última revisión.

[fdodino]

Cierro el issue, voy a abrir otro para migrar las 4 funciones que quedan.