Claudio, cómo va tanto tiempo? Algo interesante en cuanto al tema que planteas del "problema de self" se resuelve con esto:
http://www.dc.uba.ar/events/smalltalks/2007/programme/canibanoSmalltalks2007.pdf Estuve en la presentación de Nicolás en Smalltalks2007 y estuvo muy interesante :-) Saludos, Guiye Nicolas Chillo escribió: > Gabo: > El problema con lo que vos decis es que la clasificación actual es > demasiado arbitraria. A no todos les sirve por ejemplo que un Entero > se clasifique en LargeInteger y SmallInteger. > > A partir de estas clasificaciones arbitrarias, surge la necesidad de > buscar nuevas alternativas. Aca entran en juego los mecanismos de > herencia multiple, de traits, etc. Igualmente, yo coincido en que > estos mecanismos no deberían ser soluciones a reutilización de codigo. > > Saludos, > Nicolas Chillo > > El día 25 de abril de 2008 11:05, Gabriel <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> escribió: > > En el congreso de Smalltalk hubo una charla en la que explicaron > como implementar "true delegation" (delegacion sin el problema de > self que nombras) en Visualworks. Igualmente la implementacion es > un poco estoterica y varia dependiendo de la distribucion de > Smalltalk. Pero es interesante... > > Habria que revisar si en realidad se requiere herencia multiple o > el problema pasa por otro lado (poder compartir comportamiento > entre varios objetos de una manera mas flexible). > > El principal problema viene de pensar que la herencia esta para > "reutilizar codigo". Grave error, las clases estan para clasificar > conocimiento, y de alli su nombre CLASE. > Y cuando se clasifican cosas, por ejemplo animales, y tenemos a > una clase de animales, decimos que estos tienen algo en comun, > algo que los hace propio de esa clase. Que los hace propios de esa > clase? bueno, por ejemplo el funcionamiento de su aparato > reproductor. En Smalltalk esto implicaria que gran parte del > comportamiento relacionado con el aparato reproductor podria estar > compartido por todos los animales pertenecientes a esta clase. > > Que sentido tiene tener herencia multiple? no se estarian > clasificando cosas mezclando el punto de vista? > > Habria que revisar tambien si en realidad la herencia (que es una > herramienta muy util) no se exige en Smalltalk de manera muy > estricta. ¿Podria en su lugar contarse con un ambiente como Self > en donde todo esta basado en prototypos y delegacion y en el mismo > ambiente poder utilizar clases para ir generalizando el > conocimiento adquirido con los prototipos? > > Saludos > Gaboto > > > > > On 25/04/2008, *Claudio* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Hola Bruno, > Cada vez que alguno sugiere la necesidad de la herencia > múltiple en el paradigma de Objetos, los que consideramos que es > innecesaria (y perjudicial) mostramos que esas supuestas > necesidades > pueden satisfacerse con delegaciones. Esto es exactamente lo > que Vos > estás haciendo en tu solución. Tu Dragón recibe un mensaje que no > tiene implementado entonces lo delega en sus colaboradores, una > INSTANCIA de Lagarto y una INSTANCIA de Pájaro. Extrañamente se lo > enviás a ambos en lugar de "elegir" de algún modo quién lo > responderá. > Ahora supongamos que tu mecanismo de selección (on: Error, result > notNil:...) funcionara... entrás en el famoso "Problema de > self" que > podríamos resumirlo en lo siguiente: > Supongamos que La Clase Pájaro implementa #message1 y > #message2 y la > clase Dragón implementa el mensaje #message2. > Supongamos que tu Dragón recibe un mensaje #message1 que no > implementa, y entonces lo delega y lo resuelve el Pájaro. > Supongamos ahora también que dentro del código del método > correspondiente a #message1 en la clase Pájaro , hay una línea que > dice: > self message2. > .... > Si estuviésemos hablando de Herencia, es decir, si Dragón > heredara de > Pájaro, el objeto que está ejecutando #message1 es UN DRAGÓN, > aunque > use la implementación de la clase Pájaro, pero es un dragón, > por lo > cual, en la línea "self message2" self es el dragón y el > message2 que > se ejecuta es el de dragón.... en cambio en tu ejemplo, el > objeto que > está ejecutando #message1 es un pájaro, entonces cuando la > línea "self > message2" ejecuta el método "incorrecto".... y ni hablar de lo que > pasaría si el pájaro does not understand #message2 ... > Me quedan muchas más preguntas, como por ejemplo que pasa con > super.... pero no lo quiero hacer muy largo!!! > Abrazo, > > Claudio > > > > On 19 abr, 16:59, "Bruno Buzzi Brassesco" > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > > Discutiendo con un amigo que decía que Smalltalk no tenia > herencia múltiple. > > > > Aunque sea discutible la necesidad de herencia múltiple, me > pregunte cuan > > rápido se podrá implementar herencia múltiple en Smalltalk y > poner a prueba > > su flexibilidad. > > > > En "7 líneas de código" o 5 minutos ... hice esto: > > > > Se puede discutir sobre la validez de la implementación (la > variable # > > superinstances y sus implicaciones) pero NO es el punto central. > > > > Lo central es que si en 5 minutos se puede hacer esto, que > será después de > > estar un año trabajando sobre un tema… > > > > Implementa algo así en C# (u otro) valor!!! > > > > > Object subclass: #HerenciaMultiple > > > > instanceVariableNames: 'superinstances' > > > > classVariableNames: '' > > > > poolDictionaries: '' > > > > classInstanceVariableNames: '' > > > > initialize > > > > super initialize. > > > > superinstances := OrderedCollection new. > > > > superinstances addAll: (self superclasses > collect: [:each | each > > new initialize]) > > > > doesNotUnderstand: failedMessage > > > > superinstances do: [:each | | result | > > > > [result := each perform: > failedMessage selector > > withArguments: failedMessage arguments] on: Error do: [:ex | ]. > > > > result ifNotNil: [:value | ^value]]. > > > > ^super doesNotUnderstand: failedMessage > > > > Object > > > > Lagarto > > > > Pajaro > > > > HerenciaMultiple > > > > Dragon > > > > Dragon class > > > > superclasses > > > > ^OrderedCollection with: Lagarto with: Pajaro > > > > Saludos, > > > > bruno > > > > No virus found in this outgoing message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.2/1387 - Release > Date: 4/19/2008 > > 11:31 AM > > > > > > > > > -- Guillermo Sapaya InfOil S.A. Gerente de Desarrollo (+54-11) 4542-9999 x122 [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "ClubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
