¿Tanto te costaria llamar a esto getter?
globalvars = [target => …, player => …]
unitName(t) => return globalvars[t]
¿Lo prodrimos llamar getUnitNameByType? ¿Actua de accessor?
Evidenemnte, si te metes a hacer consultas y operacions complejas deja de ser un “accessor”. Indistintamente, un método no deja de ser una función o acción que puede realizar un objeto… como el toString de un objeto…
has tardado en faltar al respeto.
Pero si esta todo centralizado… no és más fácil… solo afecta a un punto… ¿Me puedes pegar el contenido de esa función para ver que tal es la otra realidad?
Espera, que te ayudo un poco con lo que vas ignorando:
Lo que ves es básicamente la eterna lucha entre Programación orientada a Objetos (Anzoris) y Programación Modular (Melaendral) entre si y a la vez con(contra) la Programación Estructurada (Blizzard y su BD).
Si a alguno de los 2 os molesta la imagen, decídmelo y la quito.
No, no lo quiero llamar un getter porque no es un getter. Porque un getter es inherentemente un método que permite acceder al atributo de una clase concreta. Lo que te he puesto es una función, que no depende de una clase. Y una función y un método no es lo mismo.
No puedes llamar a las cosas como te de la real de la gana y pretender que se te entienda.
Honestamente, no te recomiendo que te de clases que vas a suspender
¿Quieres buenas prácticas, algorítmica, patrones o directamente un lenguaje de programación? Te puedo recomendar buenos libros y cursos si quieres
¿Pegar el contenido de esa función? Pero que te crees, ¿Qué trabajo para Blizzard?
Tu me has empezado a hablar de la interfaz, que resulta que es un tema con el que he trabajado por afición, de la cual solo tenemos una API con la que Blizzard nos permite interactuar con la información del juego. Y yo te digo como funciona, sin más ni menos.
¿Quieres aprender como funciona la interfaz del wow? ¡Puedes hacerlo! Que para algo están los addons y sus recursos:
Ahí tienes toda la interfaz del juego. ¿Quieres tocar la función UnitName. Veamos su riesgo. Nada, solo se usa en 2781 ficheros de la interfaz, nada es cosa de tocar solo en 3+4 sitios.
Veamos cuanta veces se usa para “consultar” el nombre del personaje. Bueno, son solo 154 usos, muchos de más de los has “acotado”.
Veamos como se utiliza, no sé, por ejemplo en el chat, que dices que es fácil:
A ver, si tu mismo te das cuenta.
Bueno, yo realmente lo que defiendo es la interfaz se hace con Lua siguiendo un paradigma de programación imperativo. NO tiene sentido alguno pretender que haya elemento del paradigma orientado a objetos, como son los getter y setters.
Pero me has sacado una carcajada, así que lo dejo ya.
Se lleva pidiendo casi 20 años y muchas veces lo han plantado y no han encontrado la forma.
Los addons no intervienen con el código del juego. Que hayan añadido cosas de algunos addons es porque no interfieren ni dan tantos problemas con los códigos del juego.
Chat GPT o como se escriba, hace poco le añadieron el modo profesor para enseñar como en una clase.
Madre mía… que yo entiendo que saques el tema de métodos y funciones para mover la portería… o pa lo que sea, tu sabrás… pero por favor… Los “accessors” / getters o setters en lenguajes que solo hay estructuras de datos (no hay objetos como tal) o que se esta programando de forma structurada (sin uso de objetos), por mal que te pese, se implementan, ya que con ello se intenta evitar la modificación de la estructura fuera del setter implementado o acceder al dato fuera del getter implementado. Tiene otras ventajas, pero entiendo que ya las sabes.
Al hablar de setter o getter has asociado, no sé por qué, a que hablamos de lenguaje orientado a objetos, cuando todo el rato he hablado de funciones, lo que la conclusión debería haber sido más similar a la de Nei: me está hablando de lenguaje estructurado.
Y por definición, un método es una acción o función / subrutina asociada a un objeto y encapsulada en este. Dicho de otra forma, un método es una función encapsulada dentro de un objeto y que actúa sobre este tenga el nombre que tenga. NO DEJA SE SER UNA FUNCIÓN encapsulada.
Hablar de getter o setter, aunque habitualmente se usa en lenguaje orientado a objeto, no és exclusivo de este.
Madre mia… Nei quizás se acuerde de mi formación o profesión.
Tengo clarisimamente que no… ¿Pero entonces estás haciendo suposiciones que te convienen o no?
Solo hay que tocar en un sitio: el body de la función… es la gracia de hacer lenguaje modular… como devuelve una tupla, le añades un campo al final que sea surname y ahora solo tendrás que tocar en esos sitios donde llamas a esa función y quieres que se vea el surname.
Y si toca refactor… toca refactor!
De verdad…
Interface/AddOns/Blizzard_APIDocumentation/BaseAPIMixin.lua
BaseAPIMixin = {};
function BaseAPIMixin:GetType()
return assert(false);
end
function BaseAPIMixin:GetPrettyType()
return self:GetType();
end
function BaseAPIMixin:GetLinkHexColor()
return "ffffff";
end
function BaseAPIMixin:GetName()
return self.Name;
end
function BaseAPIMixin:GetFullName()
return self:GetName();
end
¿Esto es una metatabla de LUA con getters? corcholis!! De todas formas, las últimas versions de LUA permiten crear clases y objetos. Re-Re-Re-Corcholis.
Espera, que hay más:
Blizzard_EncounterJournal/Cata/Blizzard_EncounterJournal.lua
local EJ_TIER_DATA =
{
[1] = { backgroundAtlas = "UI-EJ-Classic", r = 1.0, g = 0.8, b = 0.0 },
[2] = { backgroundAtlas = "UI-EJ-BurningCrusade", r = 0.6, g = 0.8, b = 0.0 },
[3] = { backgroundAtlas = "UI-EJ-WrathoftheLichKing", r = 0.2, g = 0.8, b = 1.0 },
[4] = { backgroundAtlas = "UI-EJ-Cataclysm", r = 1.0, g = 0.4, b = 0.0 },
[5] = { backgroundAtlas = "UI-EJ-MistsofPandaria", r = 0.0, g = 0.6, b = 0.2 },
}
function GetEJTierData(tier)
return EJ_TIER_DATA[tier] or EJ_TIER_DATA[1];
end
Ups! un getter fuera de una metatable… nmm, me suena a una suposición:
Si, esto es un getter / accessor para una structura de datos en programación estructurada y en este caso, en modulos con variables locales que solo se acceden a ellas fuera del módulo mediante el getter que toque.
Pero si yo creo que ahora nos comenzábamos a entender…
Vale, si para ti un getter solo implica que se llame get, pues nada. Lo siento si soy un purista de la ingeniería del software y el desarrollo. Te pregunto, ¿y si encuentras una función que se llame lambda también me vas a decir que hace uso de expresiones lambda? Porque ya puestos.
En serio, tío. Lo reconozco, soy un extremista con la precisión de los términos. Pero es que tu mismo lo dices, es una tabla, no es un objeto. Por definición por tanto no tiene ni getter ni setted, por mucho que tu como desarrollador le pongas el nombre que quieras a una función que extraiga información de esa tabla. Como si le quiero llamar a una función GPU y digo que hago uso de computación con GPU. O le pongo a una función thread y digo que es paralela.
Y en serio, me cansa muchísimo que los términos se empleen “porque si” o como sinónimos, como si no tuviesen una significancia subyacente. Me pasa lo mismo con la gente que usa objeto o clase como sinónimo. O estructura, en este caso. ¡Una estructura por definición no tiene métodos, solo es una colección de variables!. No puede tener getter ni setter.
En serio, podría escribir un libro de términos que se emplean indistintamente y me hacen hervir la sangre. Otro ejemplo, este último que me pasó esta misma semana, es el uso de parámetro y argumento como sinónimos, que me dan ganas de…
¿Qué no te referías canónicamente al término? Me lo dices y terminamos la discusión en cero coma. Pero no me discutas algo que tu mismo me terminas diciendo.
Y aún así, te vuelvo a decir, no estamos hablando de lo que diantres sea el código que me has puesto para validar tu discurso, yo te he dicho exactamente como se acceder al nombre del personaje que es de lo que va el tema.
Y se accede por medio de una función llamada UnitName que sirve para obtener el nombre de todas las entidades del juego, ya sea el personaje o cualquier otro.
Por lo que modificarla, implica más que solamente el nombre del propio personaje. Y dado que hay un montón de elementos del juego que se basan en entidades, tanto visibles como invisibles, yo sería algo que no tocaría ni aunque fuese por casualidad.
¡Y dale con usar términos de forma arbitraria! Si vas a añadir una nueva función no es una refactorización, es una reescritura de código. La refactorización implica que no se cambia la funcionalidad del código, solo se mejora su eficiencia. Si se cambia el comportamiento, no es una refactorización.
Y aún así, ¡DE ESO ESTAMOS HABLANDO! De que para añadir esa funcionalidad hay que reescribir muchísimo código, por lo que no merece la pena ese esfuerzo titánico.
Aún así, perdón si soy un excesivo purista. Si esto fuese el mundo real, te invitaba a una cerveza para seguir discutiendo
Yo agoté mi paciencia en el año 1993 y todavía estoy esperando que me la repongan
No, he explicado un ejemplo de encapsulación usado por blizzard donde usan accessors (getters y setters). Sigo pensando que erras al pensar que un getter o setter es solo para lenguaje orientado a objeto. Son funciones que se usan en las encapsulaciones (ya sea un objeto donde reciben el nombre de método o no) con un objetivo muy concreto como he explicada ya.
Mutator_method en la Wiki en:
In computer science, a mutator method is a method used to control changes to a variable. They are also widely known as setter methods. Often a setter is accompanied by a getter, which returns the value of the private member variable. They are also known collectively as accessors.
The mutator method is most often used in object-oriented programming, in keeping with the principle of encapsulation […]
Mutator methods may also be used in non-object-oriented environments. In this case, a reference to the variable to be modified is passed to the mutator, along with the new value. In this scenario, the compiler cannot restrict code from bypassing the mutator method and changing the variable directly. The responsibility falls to the developers to ensure the variable is only modified through the mutator method and not modified directly.
Vamos, que fuera de un objeto se usan con la misma finalidad que dentro del objeto, aunque los llamemos funciones:
Así que accessors no solo se implementan en lenguaje orientado a objetos… porque lo que les define es su función, como bien dices con lo del lamba, como bien se ve en el código de blizzard y como llevo diciendo hasta el momento.
De hecho, en programación modular con repositorios de datos es una buena práctica usar accessors. De la misma manera, que declarar como variables locales del módulo (encapsulamiento, variables “privadas”) aquellas que no queremos que se puedan manipular desde fuera y que, por lo tanto, para su acceso, hace falta implementar un getter.
En ninguno momento he dicho nada similar, he dicho que se implementan accessors para acceder o modificar los datos de una estructura de datos en un lenguaje modular. Evidentemente no se implementa en la estructura de datos (no és posible).
Una metatable de LUA es UN OBJETO. De la documentación de Lua:
Tables in Lua are neither values nor variables; they are objects. If you are familiar with arrays in Java or Scheme, then you have a fair idea of what we mean.
Por ello te puse un ejemplo de metatable con accessos cuando dijiste esto:
Y otro ejemplo con programación modular y encapsulamiento, también con accessors, de blizzard.
En las nuevas versiones de lua te permiten definir clases y crear instancias de dicha class. No he encontrado ninguna.
Así que, por lo menos yo, veo bastante evidente que Blizzard trabaja con objectos (metatables) a los que les define métodos accessors (no ha todas) y a la vez, programa de forma modular (encapsula parte del código) y implementa accessors para que desde fuera del modulo se pueda acceder o modificar una variable o objeto definido como local en el modulo (de hecho, en mi ejemplo, define un función accessor (getter concretamente) para obtener un atributo de un objeto definido como local al cual no le ha implementado metodos accessors y mutators).
El código que te pasado sirve para validar lo que hablamos a nivel de interface. Si es una metatable que tiene la información tal que así, muy resumido:
local el =
{
['target] = { name = "aaaa", server: 'aaaaaa' },
['player'] = { name = "bbbb", server: 'cccc' },
}
Y se actualiza mediante eventos al entrar en una party, al entrar al juego, al invocar una pet, etc. y se accede tal que asi:
function UnitName(type)
return el[type];
end
Y se recoge los valores tal que asi:
name, server = UnitName(type)
Siendo por defecto el UnitName(type) el nombre solamente (cosa automàtica), añadir en la metatable, al final del atributo player el surname, no te debería afectar al código que has programado hasta ahora donde se hace uso de UnitName. Alli donde se quiera, a partir de ahora tambien recoges el surname:
name, server, surname = UnitName(type)
concat(name, ' ', surname)
como seguramente se hace: concat(name, ' -', server)
Si añades atributos en el futuro, creo que en lua era:
name, server, _, nuevo = UnitName(type)
Pero añadir al final, no debería romper el código actual a nivel de interface. Evidentemente, toca hacer algunas cosillas en los eventos que actualizan la metatable cuando manipulan los datos de un player y cositas fuera de interfaz ya comentadas.
Creo que le das un sentido a mis palabras que no las tienen. Si después de hacer lo otro, toca refactor, pues le das al refactor! Por eso el comentario viene después de comentar las modificacions. És como chungo que una cosa se llame UnitName cuando lo más descriptivo seria un getUnitNameByType (que lo comenté hace tiempo).
Pero es que es lo que yo te digo, soy un purista. ¿Podemos hablar de encapsulación si como dices se puede saltar esa restricción?
Yo opino que no. Y por eso no estás usando un getter y setter, estás usando algo que “simula” ese funcionamiento.
Que crees un método setter y getter en un entorno donde no tienes capacidad de controlar que la variable solo sea consultada o manipulada por esos métodos, no hacen que se conviertan en métodos setter y getter.
De igual manera, que para mi esto no es una valla, por mucho que puedas entrar y salir cruzando la puerta:
Y te digo, los puedes emular, pero no usar. Esa es la clave para mi. Por tanto, si estás emulando su comportamiento, entonces no los tienes disponibles. Puedes usar una piedra para clavar un clavo, pero eso no la convierte en un martillo.
No, en LUA una tabla es un array que permite comportarse como un objeto, pero no lo convierte en un objeto.
De hecho, la documentación en el primer párrafo indica eso, que son estructuras de datos, y solo usa el ejemplo de objetos para distinguir de los arrays de C o Pascal.
Pero la cabla no permite encapsular ni acceso controlado, no almacenan atributos, almacenan pares clave-valor, no implementan métodos, sino que usan funciones. Para temas de herencia o polimorfismo requiere de un mecanismo externo como las metatablas. Se comporta casi como un objeto, pero no es un objeto.
Y si, seguramente Blizzard va incorporando las mejoras del lenguaje con cada mejora del motor del juego, pero el tema del nombre lo sigue manejando igual.
Pues eso es lo que estamos hablando todo el rato, que para ti toca “hacer cosillas” para mi supone una bomba de relojería en la que no tienes control de que o donde puede fallar.
No, si después de añadir una funcionalidad, el software no funciona adecuadamente, no es refactorizar. Es escribir código para integrar la nueva funcionalidad. La refactorización no cambia la funcionalidad, solo la eficiencia.
Si me disculpo, porque sé que mi manera “cuadriculada” de entender los términos en muchas ocasiones me busca problemas.
Soy de los que si les dices que has perdido a tu mascota, te puedo llegar con una rata de la cloaca y decirte “¿Es esta?”. Porque entiendo que una rata puede ser una mascota.
Y si me dices que has perdido tu perro corgi, por mucho que vea un beagle, no te lo voy a llevar aunque resulte que sea ese perro, pero que le llamas corgi porque se parecen
Yo si toco algo, lo primero es intentar hacer un entorno que sea “cagao y pintao” al real, en todo, donde si hay fallos en dicho entorno de prueba, en el real tambien. Con la diferencia en que con el de prueba puedes poner a prueba todas las ideas locas para intentar solucionar algo que no va a repercutir en el servicio en vivo.
Pero claro, para eso hace falta montarse una barraca para ello, y que haya gente que se dedique a ello. Por poder se puede intentar, pero vamos, como el tema de la bolsa de 16 casillas, es una pijada que realmente podria trastocar todo, y como no es una prioridad, pues los devs lo apartan.
Por pijadas la cosa puede directamente caerse, por esa clase de cosas, bastantes sitios todavia siguen estancados en sistemas que datan de la epoca de mis padres
Aun así, como informatico, hay gente que esta dando mucho por “sentado” el como tiene montado la barraca Blizzard, y sinceramente, la gente o incluso la mismisima Blizzard o los propios creadores del sistema pueden decir lo que quieran… pero yo, si quiero saber como funciona realmente algo, tengo que estar directamente yo metiendo mano al sistema, trastear con el, para saber por mi mismo como es el tinglado. Es mas, creo que alguna vez cuando Blizzard sacó puestos de trabajo para eso, habia gente que flipaba por que pedia un conocimiento que data de “la era de los dinosaurios” y que nadie sabia como funcioba el asunto con los programas de ahora, montados en el “ahora”.
Si tengo una class instancia y tengo unos un atributo declarados como publicos, da igual los accessors. Te los puedes saltar.
Si tengo una class instancia y declaro atirbutos como privados, solo puedo acceder via accessors.
Des de dentro un objeto, puedo acceder a sus atributos ya sean privados o públicos. Son del mismo contexto.
Lo trasladamos a módulos:
Si en un modulo declaro una funcion o variable como publica, da igual los accessors.
Si declaras una variable / funcion de un modulo como local, solo puedo acceder via accessors.
Des de dentro el módulo estamos en el mismo contexto y puedo acceder a todo lo definido en él.
Ejemplo en CommonJS:
Una variable local del módulo, se declara como de forma habitual: const / let. No és accesible desde fuera el módulo mediante un import.
Mediante un export haces accesible una variable fuera del módulo. Si queries que solo sea lectura, la declaras como local y le defines un getter: export.function get => return (that.myLocalVar). Ahora es accesible fuera del modulo mediante un import {get} from file.
Des de dentro de un módulo tienes acceso a todos las variables, pues es el mismo contexto, de hecho, recomendable hacer un const that = this para hacer referencia al modulo dentro del mismo modulo (no voy a entrar en detalles)
Ejemplo de Lua:
Una variable local del módulo, se declara como local name = value. No és accesible desde fuera el módulo mediante un import.
Si se quiere que sea accesible desde fuera del modulo mediante un import hay que hacer un return al final del modulo, ya sea de la variable o de una metatable que contenga la variable o de un getter que de acceso a la varaible (según caso anterior CommonJS).
Des de dentro de un módulo tienes acceso a todos las variables, pues es el mismo contexto.
Ejemplo en C:
Declaras como static. No és accesible desde fuera el módulo mediante un include.
Para acceder fuera del modulo → implementar accessors. #include file // extern type get(), extern void set(type).
Des de dentro de un módulo tienes acceso a todos las variables, pues es el mismo contexto.
Por lo tanto, no es cierto lo que dices en todos los lenguajes. No te puedes saltar la restricción. Si que es verdad que hay lenguajes mas permisivos, python por ejemplo, que si pones _ lo estas marcando como privado pero bueno… es mas una buenas practicas.
Si, hay accessors en su definición más estricta en lenguajes que permiten la programación modular. Si, hay setters y getters más allá del lenguaje orientado a objetos (a este ejemplo y a la fuente que te puesto con anterioridad me remito).
No entiendo por qué hablo todo el rato de metatables, pero me hablas de tables… luego la documentación de lua te dice como con metatables implementar objetos, herencias, control de acceso… pero tampoco… y yo me pierdo…
De todas formas, hay lenguajes que las arrays, por ejemplo, se consideran objetos porque son una instancia de una clase base con métodos predeterminados, algo muy parecido a la metatable; puedes definir solo su contenido prácticamente y yo no voy a llevar la contraria a Mozilla. Igual que los objetos mas básicos de js vanilla.
De la misma forma, que hay lenguajes orientados a objetos que eso de la polimorfia y la herencia… bueno, lo llevan regulin; o otros que no te permiten definir el control de acceso, que definen todos los métodos como públicos…
Y falta python, que olvídate de atributos o métodos privados porque usa name mangling en las clases, lo que te permite saltarte la encapsulation echando un vistazo a dir(objeto); se implementan accessors, te los puedes saltar y el consenso sigue siendo que es un lenguaje orientado a objetos pq el name mangling esta aceptado.
Que se que en el saco de purista entra todo… pero hombre ya! xD
El refactorizar no es simplemente para la eficicencia. El uso más comun es facilidar la comprensión del código
Cosa que encaja completamente con:
De hace mucho ya…
En ningun momento me pronunciado en tus terminos para hablar de refactorizar. Cuando he hablado de implementar nuevas funcionalidades lo he dicho literal:
Bueno, creo que eso es primordial! En su momento, en este hilo, ya mencioné que para algo estan los servers de pruebas y las betas internas.
Que no siempre te garantiza que si funciona en desarrollo vaya tal cual en producción, pero es el camino mas sensato.
Esto a nivel de interfaz, Azoris ha puesto un repositorio de git. Por mi parte, ya había hecho algún addon para uso personal y modificados otros con cosas para “mí”.
Mi opinión es que no es agradable por varios motivos, pero entiendo que alguien que trabaja cada día con ello lo tiene mucho más por la mano y tiene la suficiente experiencia para afrontar retos de este tipo. No tengo por qué pensar que está trabajando ahí sin saber como va…, no se, de alguna maner pasarian la entrevista xD. Extensible a los de backend.
A más, a nivel de interface llevan tiempo haciendo cosillas y están implementando cosas nuevas de cara a TWW. Esta estuvo abonando muchísimo tiempo, lo que me lleva a pensar (quizás erróneamente) que ahora tienen más personal capacitado y focalizado en la interfaz.
Si no hacen más que despedir cada 2x3 y no contratan, incluso hace pocos meses despidieron el 90% de asistencia en todo el mundo y los que quedan les quedan pocos meses hasta que tengan bien apunto la IA de asistencia.
