Dictionary: generar una implementación que tenga entries como atributo en Wollok

[fdodino]

Actualmente está utilizando un atributo wrapped en la implementación nativa de Xtend. Podemos directamente utilizar entries de la misma manera que trabaja wollok-ts.

https://github.com/uqbar-project/wollok-ts/blob/646050ad4a3a501fee9856b15e8deabd70f5bc2b/src/wre/lang.wlk#L867

[lspigariol]

Justo de los diccionarios tenia desde hace tiempo una idea a medio especificar. Lo que quería es que fueran más polimorficos a las colecciones, aunque con diferente forma de acceso individual. En definitiva, que los foreach, filter y demás, sólo trabajen sobre los valores. En ese cambio, los pares podrían ser transparentes, que no sean accesibles desde afuera ni necesarios para usar el diccionario.

El mar., 1 de oct. de 2019 8:40 p. m., Fernando Dodino < notifications@github.com> escribió:

Actualmente está utilizando un atributo wrapped en la implementación nativa de Xtend. Podemos directamente utilizar entries de la misma manera que trabaja wollok-ts.

https://github.com/uqbar-project/wollok-ts/blob/646050ad4a3a501fee9856b15e8deabd70f5bc2b/src/wre/lang.wlk#L867

— 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/1826?email_source=notifications&email_token=ACZRXG6DM6XKKLIZ4WL2CJDQMPNYLA5CNFSM4I4QAMU2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HO7WDCQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACZRXG2NBEHVHGCDKDW3WWLQMPNYLANCNFSM4I4QAMUQ .

[lspigariol]

Agrego especificación:

class DictionaryX{

//1) Dejar como están:
method put(key, value) native

method basicGet(key) native

method getOrElse(key, closure) {
    const value = self.basicGet(key)
    if (value == null) 
        return closure.apply()
    else 
        return value
}

method get(key) = self.getOrElse(key,{ throw new ElementNotFoundException(message = "there is no element associated with key " + key) })

method values() native

method isEmpty()  
method size()

//2) Modificar:
// reemplaza a containsValue()
method contains(value) = self.values().contains(value)

//reemplaza al actual remove 
method removeWithKey(_key) native
//agregar un nuevo remove, que reciba el valor a eliminar (y elimine su primera aparición, como en List) 

// reemplazar implementacion nativa por una que haga forEach en los values 
method forEach(closure) { self.values().forEach(closure) } 
// agregar otro similforEach que haga el forEach con bloque de dos parametros.  

// Revisar
override method toString() {
    var result = "a Dictionary ["
    self.forEach { key, value => result = result + (key.printString() + " -> " + value.printString() + ", ") }
    if (self.size() > 0) result = result.substring(0, result.length() - 2) 
    return result + "]"
}

//3) Agregar:
method max(closure) = self.values().max(closure)

//idem 
method min(closure) 
method all(predicate) 
method any(predicate) 
method anyOne()
method fold(closure)   
method map(closure)

method find(predicate) //Retorna el value
method findOrElse(predicate, continuation)

method filter(predicate) // Retorna new Collection()

//4) Discusión
   literal de Coleccion vacía  

//Agrega con clave igual a elemento.
//a) Logica de set para evitar claves duplicadas?   
method add(element) {
    self.put(element, element) 
}
//b) error en caso de duplicados    
method addx(element) {
    if( self.basicGet(element)== null)
        throw new Exception()

    self.put(element, element) 
}

// Concatener con otras colecciones

}

[fdodino]

Mmm... no me termina de convencer, yo preferiría mantener los dictionaries cortos de implementación y quizás vengo del palo de Java/JS, pero tanto el Map de Java como el de Javascript tienen un formato más minimalista, que prefiero por sobre la propuesta de Lucas.

[npasserini]

A mí me parece que pensar al dictionary como colección es generalmente forzado. En algunos lenguajes se homologa con la colección de values, en otros con la de entries... siempre resulta confuso. Creo que el dictionary tiene que entender keys(), values() y entries() y ahí tenés las colecciones que necesitás y todos los iteradores posibles, sin ambigüedades.

Lo que sí me parece que nos viene faltando es tener un literal.

El mié., 9 de oct. de 2019 a la(s) 08:50, Fernando Dodino ( notifications@github.com) escribió:

Mmm... no me termina de convencer, yo preferiría mantener los dictionaries cortos de implementación y quizás vengo del palo de Java/JS, pero tanto el Map de Java https://docs.oracle.com/javase/8/docs/api/java/util/Map.html como el de Javascript https://developer.mozilla.org/es/docs/Web/JavaScript/Referencia/Objetos_globales/Map tienen un formato más minimalista, que prefiero por sobre la propuesta de Lucas.

— 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/1826?email_source=notifications&email_token=ABDLKONF2FWNWJCCIBWD6T3QNXARBA5CNFSM4I4QAMU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAXTXVQ#issuecomment-539966422, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOP5GAX6DBONYMNBF23QNXARBANCNFSM4I4QAMUQ .

[fdodino]

+1 a tener un literal (creando otro ticket), no se cuál será mejor, me gusta el de Xtend, pero creo que ya lo estamos usando para Set.

[npasserini]

Yo creo que hay que ser cuidadoso con estas cosas, el exceso de código wollok vs. nativo lleva a problemas de performance.

El mar., 12 de nov. de 2019 a la(s) 20:49, Fernando Dodino ( notifications@github.com) escribió:

Actualmente está utilizando un atributo wrapped en la implementación nativa de Xtend. Podemos directamente utilizar entries de la misma manera que trabaja wollok-ts.

https://github.com/uqbar-project/wollok-ts/blob/646050ad4a3a501fee9856b15e8deabd70f5bc2b/src/wre/lang.wlk#L867

— 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-language/issues/33?email_source=notifications&email_token=ABDLKOISSZ3DYR3R2Y7AYL3QTM6JFA5CNFSM4JMLQ4WKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HY3C57A, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDLKOLEILWDYJ35ZCDBKS3QTM6JFANCNFSM4JMLQ4WA .