ambar-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mine-dev] Métodos demodificación de atributo s en Sala.py


From: Gabriel Pulido de Torres
Subject: Re: [Mine-dev] Métodos demodificación de atributo s en Sala.py
Date: Mon, 19 May 2003 19:35:14 +0200

A ver, empezando por el uso de self.atributo dentro del mismo parseado de la
sala en vez del self.__atributo
Luego cuando leemos una descripción del xml (parseandola) llamando a un
método que es algo así como "addDescripción" en vez de copiar a capón todos
los atributos ya que así se pueden añadir descripciones de forma coherente
desde varios sitios aparte del parseado y siempre se hará igual... (y lo
mismo para las salidas, hummm se me acaba de ocurrir que una sala podría
cambiar dinámicamente dentro del juego al estilo matrix de ups ya no está
esa puerta ahi, en ppio puede ser un lío pero puede ser algo interesante en
la versión n de mine cuando n tiende a un numero bastante grande ;) lo
siento soy matemático no lo puedo evitar
Ya se me iran ocurriendo cosas, la idea es añadir funciones que hagan lo
mismo que bloques de código que se usan a pelo pq en un principio sólo se
iba a hacer ahi eso específico, pero yo me estoy encontrando de que me será
más fácil definir funciones que hagan bloques pq comod e todas formas lo voy
a acabar haciendo pq las necesito así no está el código duplicado...
No se si me he explicado bien :)
Sobre lo de la validación de los datos, lo puede hacer el editor si quereis,
y poner a sin_tipo o sin_subtipo los valores que estén mal, pero ya me he
encontrado alguna sala que está mal, alguna de los Retama usa el tipo
"habitación" que no está definido. Estaba pensando tb en sacar a otro
fichero todas las constantes de ese tipo que necesite el juego... pq a lo
mejor no sólo en la sala.py se necesita saber todos los tipos de salas que
hay... De todas formas las que valido yo son estas mirar si falta algo:
TIPOS_SALA = { "Población" : [  "calle",    "callejón",     "plaza",
                                    "portal",   "pasadizo",     "arco",
                                    "puerto",   "embarcadero",  "azotea" ],

                "Edificio" : [ "salón","habitación","pasillo",
                                "escaleras","vestíbulo","cuarto sin
ventanas",
                                "sótano", "calabozo", "alcantarilla",
"tejado",
                                "balcón", "letrina" ],

                "Campo" : [ "llanura", "bosque", "claro de bosque",
"colina",
                            "valle", "pantano", "páramo", "desierto" ],

                "Agua" : [ "ribera", "costa", "acantilado", "cala", "rio",
                            "lago", "mar", "islote" ],

                "Montaña" : [ "cima", "ladera", "promontorio", "grieta",
                                "desfiladero", "quebrada", "abismo",
"cornisa" ],

                "Caverna" : ["entrada", "cueva", "pasadizo", "sima",
                                "rio subterráneo", "lago subterráneo"]
               }

Sobre lo de las versiones de la sala, vale a ver si lo entiendo:
Al parsear se verifica que la version de XML del fichero es la correcta y
luego se le asigna como "version" al objeto sala la versión de atributos no?
Ok, entonces yo tengo que imprimir a fichero la versión de XML :) que sólo
está en una constante y no en ninguna variable del objeto sala creado.

Ale, seguimos con ello, ya va quedando menos ;)
Gabi

----- Original Message -----
From: "Andres Moya" <address@hidden>
To: "Gabriel Pulido de Torres" <address@hidden>
Cc: "lista_ambar" <address@hidden>
Sent: Sunday, May 18, 2003 11:01 PM
Subject: Re: [Mine-dev] Métodos demodificación de atributos en Sala.py


> El dom, 18 de 05 de 2003 a las 19:23, Gabriel Pulido de Torres escribió:
> > Hola chicos, sigo trabajando en el editor,
>
> Guay, a ver si tenemos un editor usable muy pronto (yo creo que sí ;)
>
>
> > [...]Como no
> > sabía como establecer el propierty para los métodos de modificación de
> > atributos desde fuera de la clase con la clase que heredaba, he
> > acabado por meterlos dentro de la clase. Con todo esto ahora se puede
> > modificar el atributo con: sala.atributo = "lo que sea", sin tener que
> > utilizar métodos y ganando legibilidad. Esta era la idea original no
> > Andrés?.
>
> En realidad si que se puede hacer, aunque es un poco feo:
>
> class base(object):
>
>   def __init__(self, dato):
>     self.__dato = dato
>
>   def __leer_dato(self):
>     return self.__dato
>
>   dato = property(__leer_dato)
>
>
> class deriv(base):
>
>   def __poner_dato(self, valor):
>     self._base__dato = valor
>
>   dato = property(base._base__leer_dato, __poner_dato)
>
>
> De todas formas, si que la idea era ponerlo en la misma clase, así que
> está bien como lo has hecho.
>
>
> > De paso voy a crear algunos métodos que encapsulen cosas que están
> > dentro del código. Si estais de acuerdo con esto en cuanto tenga una
> > versión más o menos completa subo la clase al CVS. En lo que respecta
> > al mine, no afecta para nada, pues ya tenía puesto el propierty de
> > acceso a datos.
>
> Esto no lo entiendo, ¿me lo puedes explicar, porfa?
>
>
>
> > Alguien me puede decir como puedo acceder a la información que está en
> > el doc del propierty? ¿se puede acceder desde código? es para
> > engancharlo como ayuda en pantalla :)
>
> Fácil: print una_sala.nombre.__doc__
>
>
> > Por cierto en el parseado de la sala, se comprueba que la versión de
> > la sala sea la misma que en VERSION_DESC_SALA pero resulta que se le
> > asigna el valor VERSION_SALA al atributo "version"
> > ¿con que nos quedamos? Supongo que es un error y que habría que
> > asignarle el valor VERSION_DESC_SALA pero no lo tengo tan claro... así
> > que decidmelo y pongo lo que sea y actuo en consecuencia :)
>
> Ojo, no nos liemos: hay dos versiones, que avanzan independientemente:
> la del fichero XML descriptor de sala y la de la clase Sala. La primera
> avanza cada vez que cambia el formato del fichero, y la segunda, cada
> vez que se pone o quita un atributo a la clase.
>
> Está bien como está ahora. La versión del descriptor de sala se
> comprueba al parsear el fichero xml. La de la clase se comprueba al
> recuperar una instancia con pickle.
>
>
> >
> > Otra cosa, ¿el usuario puede poner otro tipo y/o subtipo de los que
> > hay en la lista?. Yo no dejaría en principio que se hiciese pq puede
> > provocar que haya poca uniformidad. Además si luego se quiere usar esa
> > información para algo tendrá que ser coherente...
>
> No, sólo se admiten los tipos y subtipos establecidos. Lo que pasa es
> que el parseador de momento no valida los ficheros, asume que el maestro
> de salas no ha cometido ningún error ni escrito nada "ilegal". El
> chequeo se podría hacer ahí mismo, pero hasta ahora no hemos tenido
> tiempo. A lo mejor sería buena idea hacerlo en el editor, o tener una
> herramienta aparte para chequear los ficheros XML.
>
>
> > Ale seguiremos informando :)
> > Trotter
>
> Ale, seguiremos escuchando :D
>
> --
> Andres Moya <address@hidden>
>
> Contra la guerra global permanente.
> Foro Social Mundial - Otro mundo es posible.
>
>
>
> _______________________________________________
> Ambar-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/ambar-dev





reply via email to

[Prev in Thread] Current Thread [Next in Thread]