El día 23 de agosto de 2013 21:55, Olemis Lang <ole...@gmail.com> escribió: > 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 . > ;)
También habría que decir que "Decorator" es un patrón de diseño de la POO y que muchos ejemplos de uso de metaclase no son más que implementaciones de este patrón. > >> 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 . Desde el momento en que una subclase hereda de una clase "decorada", habría ver que más puede necesitar que no pueda adquirirse por herencia. Rizando el rizo, incluso se podría inyectar una metaclase. Nada es imposible. > > 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 . También habría otros casos donde las metaclases estarían justifiicadas como son los llamados "tipos estructurales", que en python solemos conocer por "protocolos" (eg: protocolo iterador, protocolo descriptor, etc). Es cuando necesitas que un grupo de clases que no comparten herencia tengan un comportamiento común. Este comportamiento lo declaras en una metaclase que hace de clase abstracta que cada cuál especializa según le parezca. > > 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/ -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": http://ch3m4.org/blog Buscador Python Hispano: http://ch3m4.org/python-es _______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
