2009/6/4 Esteban A. Maringolo <[email protected]> > Nahuel: > > Crear puntos a lo loco podría estresar un poco a la VM, pero los objetos > nuevos son los que más rápido se lleva el GC. Por lo que puede que valga la > pena. > Interesante lo del gc, peor por más que sean los primeros que se lleve, si vas a crear puntos a lo loco independientemente de cuando se los lleve el gc, vas a estresar la vm de todos modos no ?.
> > Lo que mencionas de tener aPoint que se mueve por toda la pantalla, me > suena más a las coordenadas de aCursor o aPointer que de aPoint. > No, no ciertamente. Si querés mover aPoint verde por toda la pantalla, es aPoint verde, no aCursor verde, o aPointer verde :). aCursor verde, podría ser el encargado de cambiar el color de aPoint; que en realidad debería ser aCursor color changer...jeje :) y aPointer podería ser el encargado de crear otro aPoin color, trazando una linea entre aPoint verde y aPoint color, siendo la linea, aPointer between aPoint verde y a Point color, y siendo el color de la linea la resta entre los valores rgb de cada point. > > > Saludos. > Igual > > Esteban A. Maringolo Nahuel > > > > El 4 de junio de 2009 9:23, Nahuel Silva <[email protected]>escribió: > > Que interesante lo que decís Juan....lo de la inmutabilidad, me suena >> conocido no se por qué... :-p. >> >> Respecto a la inmutabilidad de Point, no se si estoy tan de acuerdo; o sea >> suena lógico que un punto sea único e inmutable; pero no es lo mismo tener >> un punto que se mueve por toda la pantalla (aPointA x: algunXDePantalla y: >> algunYDePantalla, que tener, n*(xPantalla*yPantalla) posibles instancias de >> puntos a representar en pantalla, -que supondrían ser el inicial, dandose >> por muertas cada vez que un nuevo punto aparece-, sin embargo pese a darse >> por muerta cada instancia anterior, sería ridículo estar creando puntos a lo >> loco no ?. >> >> P.D.: Puntero (sust. masculino):También utilizado para golpear niños >> rebeldes >> >> Abrazo >> >> 2009/6/3 Juan Buligovich <[email protected]> >> >> >>> Aclaro algo para que no se entienda mal la palabra puntero que utilicé en >>> el >>> mail anterior. >>> Puntero = Esa varilla con que los profesores de la antigüedad utilizaban >>> para señalar en el pizarrón. O sea: un dispositivo que sirve para señalar >>> puntos de una superficie, uno por vez. >>> >>> ----- Original Message ----- >>> From: "Juan Buligovich" <[email protected]> >>> To: <[email protected]> >>> Sent: Wednesday, June 03, 2009 11:13 PM >>> Subject: Re: [clubSmalltalk] Re: setters y getters >>> >>> >>> > Hola >>> > >>> > Leyendo el mail inicial de Nahuel veo que hace referencia a un >>> concepto, >>> > que sería el motivo que lo llevó al otro a prescindir de los setters: >>> el >>> > concepto de inmutabilidad. >>> > >>> > A mí me parece que si uno está definiendo el protocolo de un objeto >>> > inmutable ¿para qué ponerle setters? ¿para qué ofrecer un servicio que >>> no >>> > se va a utilizar? ¿o mejor dicho, que se utiliza solamente en el >>> momento >>> > de la creación del objeto, y que puede ser expresado mejor como >>> > inicialización de las variables de instancia que como el seteo >>> individual >>> > de cada una de ella? >>> > >>> > Supongamos que el Point de Smalltalk fuera tal objeto inmutable, y se >>> > hubiera definido así en Smalltalk, en ese caso bastaría con el >>> protocolo >>> > #x:y: en Point class, y un método de inicialización como parte del >>> > protocolo privado de la instancia >>> > >>> > Point class>>x: xCoord y: yCoord >>> > ^self basicNew initializeWithX: xCoord y: yCoord >>> > >>> > Point>>initializeWithX: xCoord y: yCoord >>> > x := xCoord. >>> > y := yCoord >>> > >>> > Point>>x >>> > ^x >>> > >>> > Point>>y >>> > ^y >>> > >>> > etc. >>> > >>> > ¿Y porqué meterse con conceptos como el de inmutabilidad? >>> > Porque fundamentalmente un objeto inmutable tiene una existencia más >>> > simple, y no está expuesto al problema de la identidad. >>> > >>> > El tema de la identidad y de la inmutabilidad creo que es un temón, muy >>> > intereseante, pero que excede al de la temática de los setters. Tuve la >>> > oportunidad de asistir a una clase magistral que dio Dan Rozenfarb en >>> la >>> > materia de Diseño Avanzado con Objetos, y luego a otra que dio Hernán >>> > Wilkinson sobre la misma temática. Y una de las conclusiones fue que >>> los >>> > objetos inmutables son objetos mucho más simples de utilizar, por lo >>> tanto >>> > si queremos representar algo que es visto como inmutable, no perdamos >>> la >>> > oportunidad de construirlo como inmutable en nuestro modelo. >>> > >>> > Ejemplos típicos de objetos inmutables de en la "realidad" serían los >>> > objetos matemáticos, como es el caso de los números. Y como es el los >>> > pares ordenados que representan puntos en el espacio bidimensional. De >>> ahí >>> > que cuando pregunté si no hubiera sido mejor que el Point de Smalltalk >>> > fuera inmutable, Hernán respondió que sí, que no hay ningún motivo para >>> > que Point sea mutable , y que hubiera sido un mejor diseño en Smalltalk >>> un >>> > Point inmutable. >>> > >>> > Un punto representa un punto en el espacio. Y si queremos tener otro >>> punto >>> > en el espacio podemos construir otro punto, y punto. A mi entender el >>> > Point de Smalltalk más que punto es un puntero. Uno puede utilizarlo >>> como >>> > punto mediante la disciplina de no enviar los mensajes de setting, pero >>> > ¿para qué cargarse con reglas disciplinarias cuando en Smalltalk es tan >>> > fácil construir la representación del concepto deseado y luego utilizar >>> > los objetos que lo instancian con toda libertad, como al boleo? >>> > >>> > Saludos >>> > Juan >>> > >>> > ----- Original Message ----- >>> > From: "Andres Valloud" <[email protected]> >>> > To: <[email protected]> >>> > Sent: Tuesday, June 02, 2009 6:17 PM >>> > Subject: [clubSmalltalk] Re: setters y getters >>> > >>> > >>> > >>> > El problema, basicamente, es que no hay un solo punto de vista con >>> > respecto a los accessors cuando se considera la encapsulacion. Lo que >>> > entendemos por encapsulacion cambia segun nuestras intenciones, porque >>> > lo que queremos es lo que dibuja los bordes que despues nos permiten >>> > decir que algo esta encapsulado. >>> > >>> > Estan aquellos que dicen "las variables x, y, z son detalles internos >>> > de implementacion de TalClase, y por lo tanto no tiene que haber >>> > accessors [getters/setters] porque si no otros objetos podran >>> > manipular detalles internos, violando la encapsulacion". >>> > >>> > Desde el punto de vista del proposito de los objetos considerados >>> > individualmente, quiza haya algo de sentido en ese argumento. Pero >>> > los que lidiamos con las consecuencias somos nosotros, y ademas >>> > nosotros tenemos un punto de vista mas abarcador. Tambien usamos >>> > puntos de vista meta, que estan mas alla del proposito individual de >>> > cada objeto. Hay propositos perfectamente validos, como por ejemplo >>> > encontrar todas las instancias de TalClase tales que sus variables de >>> > instancia estan rotas. Tipica expresion de debugger: >>> > >>> > TalClase allInstances select: [:any | any z esCualquiera] >>> > >>> > Sin accessors, esto es imposible. Las alternativas son por demas >>> > molestas... seguro, siempre es posible usar instVarAt:, pero por que >>> > la necesidad de ser tan bruto (en el sentido de la fuerza bruta)? Y >>> > si instVarAt: existe, porque preocuparse de los accessors y la >>> > encapsulacion? Hay que redefinir instVarAt: como shouldNotImplement, >>> > acaso? Entonces, desde nuestro punto de vista, la encapsulacion no >>> > existe necesariamente siempre en el mismo lugar, porque en presencia >>> > de instVarAt: e instVarAt:put: vale cualquier cosa. Lo que si es >>> > interesante es que nosotros decimos eso porque sabemos como esta >>> > implementado instVarAt:. Los objetos no saben, necesariamente. Creo >>> > que aca es donde se arma la galleta: la confusion entre nuestro punto >>> > de vista, y el punto de vista mas estrecho de cada objeto. >>> > >>> > A mi gusto, los que programamos somos nosotros. Entonces, por nuestro >>> > propio beneficio, tiene que haber accessors para todas las variables >>> > de instancia. Esto hace mas facil debuggear objetos rotos. Ademas, >>> > facilita browsear codigo porque las referencias a las variables de >>> > instancia no pasan de 2 metodos (en algunos casos de lazy >>> > initialization se puede hacer "bien" con un metodo, pero entonces no >>> > hay setters y a veces molesta porque no hay z: para arreglar las >>> > instancias de TalClase donde z esCualquiera). Incluso facilita >>> > encontrar errores porque si interesa enterarse de cuando una variable >>> > de instancia cambia a un valor critico, la presencia del setter hace >>> > que solo haya que poner UN breakpoint. Cambiar la estructura interna >>> > de los objetos con accessors es trivial, ya que desde el punto de >>> > vista de los objetos la implementacion de los mensajes SI esta >>> > encapsulada. >>> > >>> > Pero que hacer con los objetos que mandan setters que no deberian >>> > mandar, no? Para esto, lo que me parece mejor es poner los setters >>> > que son privados en un protocolo llamado "private - accessing" o algo >>> > parecido, y no usarlos donde no corresponde. Una buena revision de >>> > codigo siempre elimina cualquier caso en el que se te escape un >>> > mensaje inapropiado. >>> > >>> > Cada tanto escucho excusas del estilo "ahh, pero como te aseguras >>> > nadie va a mandarse una guarangada?". A mi gusto, la mejor solucion >>> > es que aquellos que sientan que saben algo valioso lo compartan y lo >>> > enseñen. O sea, en vez de prohibir accessors y privarnos de sus >>> > beneficios, programemos mejor. Ademas, nada impide escribir un test >>> > que verifique que aquellos mensajes en protocols llamados 'private*' >>> > no se mandan desde cualquier lugar. >>> > >>> > Para sintetizar entonces... accessors para todas las variables de >>> > instancia porque hacen mas facil programar, browsear, debuggear, y >>> > cambiar la estructura de los objetos minimizando los cambios >>> > secundarios indeseados. Los que sean privados, favor de ponerlos en >>> > un protocolo que se llame 'private*', y no mandarlos de maneras >>> > irresponsables desde un punto de vista concreto como el que tienen los >>> > objetos individuales. >>> > >>> > Andres. >>> > >>> > >>> > 2009/6/2 Nahuel Silva <[email protected]>: >>> >> Hola gente. >>> >> >>> >> Les cuento, en el trabajo discutiendo con mi compañero sobre accesors >>> no >>> >> logramos llegar a un acuerto. >>> >> Mis críticas son que en la mitad de sus clases no estan definidos los >>> >> accesors (tanto setters como gettters) y me resulta no solo bastante >>> >> engorroso debugguear el código, ya que de repente aparece una >>> variable, >>> >> variableA y no sabés de donde carajo sale, sino que yo entiendo que >>> >> programar en smalltalk sin accesors (setters) está mal y el considera >>> que >>> >> no, argumentando historietas sobre objetos inmutables y otras yerbas, >>> que >>> >> no >>> >> quita que sa ea correcto. >>> >> >>> >> Que me pueden decir ustedes, que consideraciones puedo tener a la hora >>> de >>> >> determinar cuando usar accesors, cuándo definirlos, que criterio tengo >>> en >>> >> cuenta ?. Ésto es una pavada (tal vez), pero quiero más opiniones. >>> >> >>> >> Abrazo >>> >> >>> >> Nahuel >>> >> >>> >> > >>> >> >>> > >>> > > >>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
