On 8/23/13, Chema Cortes <pych...@gmail.com> wrote: > El día 23 de agosto de 2013 16:31, Olemis Lang <ole...@gmail.com> escribió: [...] >> >> Nótese que en este caso la diferencia entre las dos variantes consiste >> en expresar intrínsecamente el comportamiento esperado de las clases >> (registrarse en orden en el cache global, añadir el comportamiento >> esperado del sistema d plugins e.g. implement ParametricSingleton >> pattern per ComponentManager, etc ...) vs el comportamiento específico >> d una clase en cuestión (registrarse en orden en el cache de la >> interface específica ...) >> >> Como se puede ver no son conceptos equivalentes . Las meta-clases >> participan en herencia , añaden comportamientos a los meta-objetos q >> representan las clases (clases) y sus instancias (objetos) ; además >> son tipos . Los decoradores son modificadores más puntuales ... quizás >> parecidos a la situación descriptores vs __getattr__ >> >> El hecho de poner __metaclass__ en el cuerpo de la clase se puede >> solucionar haciendo la asignación en una clase base (e.g. >> trac.core.Component) y ya no es necesario repetirlo en las sub-clases >> . De hecho , en Trac + Bloodhound el hecho d tener ComponentMeta y >> todo el modelo meta es transparente ... > > No he dicho que los decoradores fueran los sustitutos de las > metaclases, sino que pueden evitar tener que usarlas en determinadas > situaciones. >
No era mi intención sugerir q antes se había dicho alguna cosa . Yo solo estaba complementando los comentarios anteriores para brindar más elementos a la hora de decidir por una u otra variante ;) > Las metaclases ofrecen la posibilidad de crear un modelo de datos > bastante consistente para el problema que necesites tratar; pero, en > mi opinion, tienen un verdadero problema con la herencia ya que las > metaclases no tienen herencia múltiple. Si necesitas combinar dos > modelos de datos distintos, cada uno con una metaclase, necesitarás > crear una supermetaclase común y modificar buena parte del código. > > En cambio, los decoradores de clases se pueden encadenar uno tras otro > sin más preocupaciones. > > Por otro lado, el valor de '__metaclass__' no tiene porque ser una > clase, ya que podría ser cualquier "callable", Entonces , en buena lid , ya no sería una metaclase sino un class factory o quizás alguna otra cosa más complicada dependiendo d los detalles d implementación . La meta-clase es un concepto abstracto d la POO q va más allá del hecho d q la variable en Python se llame __metaclass__ y acepte cualquier callable . ;) > incluso una función, lo > que se asemejaría bastante a lo que hace un decorador. +1 ... la única diferencia creo q sería la propagación de la meta-clase a las sub-clases mediante herencia , q es lo q no se logra con decoradores por ser estos un artificio sintáctico del lenguaje . Quizás hay resultados q solo se logran d forma *más correcta* al nivel de las meta-clases Por ejemplo, recuerdo ahora las implementaciones del patrón Singleton (y similares e.g. ParametricSingleton como es el caso d trac.core.Component) basados en la redefinición de __call__ en la metaclase , pero no es el único caso . D hecho , un sistema d plugins q *tiende* a ser compuesto por singletons (q puede ser un caso muy frecuente según mi experiencia) frecuentemente necesita meta-clase, porque es el mecanismo más efectivo q existe en el lenguaje para controlar la creación d instancias d las clases (... ya sé, ya sé ... __new__ + __init___ => no son suficientes , y al final son el resultado d las reglas q impone type__call__ , redefiniéndolo se puede implementar un sistema completamente nuevo a partir d una meta-clase diferente e.g. invocar un método con el mismo nombre d la clase à la C# en vez d __init__) > No veo que sea > tanta la diferencia entre uno y otro como lo pones, ... dependiendo d las circunstancias puede q no tanto ... no m atrevo a profundizar más pq realmente no sabemos cuál es el caso d uso y los requisitos reales q están involucrados en la pregunta original . > con la excepción > de que los decoradores son más explícitos. > Y éso es bueno para según > qué cosas. > No hay desacuerdo ; solo q es bueno aclararlo . [...] -- Regards, Olemis - @olemislc Apache™ Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: _______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
