[Fwd: Re: [Ambar-dev] problema con la lista]

[Andres Moya]

A ver, que este mensaje parece que está maldito... Me acabo de dar
cuenta de que en el último intento se lo mandé sólo a Pablo. A ver si
ahora llega a todos los programadores.


-----Mensaje reenviado-----

> From: Andres Moya <address@hidden>
> To: Aranarth <address@hidden>
> Subject: Re: [Ambar-dev] problema con la lista
> Date: 24 Nov 2002 16:11:32 +0100
> 
> El dom, 24-11-2002 a las 10:20, Aranarth escribió:
> > Andrés, tu correo acerca de métodos y atributos está en la cola de espera, 
> > porque supera los 40kas de longitud ¡qué has escrito!
> 
> Jopes, tampoco es tanto. Es que puse como attachment el fichero sala.py
> con unos cambios, que todavía no quiero subir al CVS porque quiero que
> les echéis un vistazo antes. En realidad el mensaje ocupa unos 43 o 44k.
> 
> 
> > Como no recuerdo la clave de password (apenas nunca me ha pasado en la vida)
> > he solicitado una nueva clave a los de savannah. Espero que tarden poco y 
> > mañana tengamos tu correo.
> 
> Se puede hacer más fácil: os copio aquí el mensaje, y luego pongo el
> attach en otro sitio. Helo aquí:
> 
> Hola, programadores :) 
> 
> He estado repasando la documentación de Python, y ya sé cual es la forma
> "guays" de escribir métodos estáticos, y también atributos públicos
> controlando si dejamos leer y escribir o no. 
> 
> Funciona a partir de Python 2.2. Técnicamente me parece una solución
> bastante buena, el único problema es que la sintaxis no me gusta mucho,
> me parece un poco fea. Aun así, creo que es bueno que nos planteemos
> hacerlo así. Además, dicen que para el próximo Python 3.0 buscarán una
> sintaxis mejor... 
> 
> En primer lugar, hay que declarar las clases del estilo "nuevo", lo cual
> significa hacer que deriven de "object". Y luego, para hacer métodos
> estáticos sería: 
> 
>   class UnaClase(object): 
>   
>     def calculo():   # notar que no lleva self 
>       return 10 * 6 
>       
>     calculo = staticmethod(calculo) 
> 
> 
> Se llaman como cualquier método estático: x = UnaClase.calculo() 
> 
> 
> Para declarar atributos públicos, se escriben los métodos "getter" y
> "setter" (si es aplicable), y luego se declara una "property": 
> 
>   class Rectangulo(object): 
> 
>     def __init__(self, x, y): 
>       self.__x = x 
>       self.__y = y 
> 
>     def get_x(self): return __x 
>     def set_x(self, x): self.__x = x 
>     x = property(get_x, set_x, doc="coordenada horizontal") 
> 
>     def get_y(self): return __y 
>     def set_y(self, y): self.__y = y 
>     y = property(get_y, set_y, doc="coordenada vertical") 
> 
>     def get_area(self): return __x * __y 
>     area = property(get_area, doc="area del rectangulo") 
> 
> Las "properties" se acceden igual que si fueran atributos públicos, pero
> el acceso pasa siempre por los métodos que hayamos definido: 
> 
>     r = Rectangulo(5, 4) 
>     print r.x, r.y, r.area 
>     r.x = 10 
>     r.y = 8 
>     print r.x, r.y, r.area 
>     r.area = 100 # Esto da error porque no hemos definido set_area 
> 
> Notar que no es imprescindible almacenar el valor en un atributo
> privado, que los accesos pasan siempre por las funciones aunque no
> pongamos (), y que podemos definir si queremos que se puedan escribir o
> no. 
> 
> ¿Qué os parece? ¿Usamos este sistema? Aquí os mando cómo quedaría la
> clase Sala transformada. En realidad no es mucho más "feo" que lo de
> definir las variables de esta manera (como lo estamos haciendo en las
> clases nuevas): 
> 
>    class Rectangulo: 
> 
>     def __init__(self, x, y): 
>       self.__x = x 
>       self.__y = y 
> 
>     def x(self): return __x 
>     def set_x(self, x): self.__x = x 
> 
>     def y(self): return __y 
>     def set_y(self, y): self.__y = y 
> 
>     def area(self): return __x * __y 
> 
> La ventaja es que el uso es en forma r.x en vez de r.x(), que es un
> futuro estándar, y que es más fácil que sea procesado por herramientas
> (por ejemplo, el generador de UML del Boa Constructor, cuando implemente
> esto). 
> 
> A ver qué opinamos. 
> 
> --- 
> Hirunatan, "language lawyer"... 
>