Hola Gallego Gracias, si, así lo tengo implementado y anda ok. Otra cosa relacionada a esto. Cuando creo un objeto Light este debe tener algunos valores por default. Lo que hago es implementar un #default que retorne una instancia con dichos valores. Algo como:
Light(class)>> default ^self new initialize Y tengo mensajes que retornan valores por default, algo como: Light>>defaultColor ^Color red Ahora el #initialize es así: Light>>initialize "Initialize the receiver" super initialize. index := TV3DEnvironment current lightManager createDirectionalLightOfColor: self defaultColor direction: self defaultDirection. self attenuation: self defaultAttenuation; specularLevel: self defaultSpecularLevel; ambient: self defaultAmbient; diffuse: self defaultDiffuse; name: self defaultName; position: self defaultPosition; range: self defaultRange; enable: true; isCastShadows: true; isManagedLight: true; isForLightmapping: false Donde por ejemplo #attenuation: hace esto: Light>>attenuation: aPoint3D "Private - Set the receiver attenuation color." attenuation := aPoint3D. TV3DEnvironment current lightManager setLight: self index attenuation: aPoint3D Me queda la sensación de que el #initialize es medio raro. El sobre todo como seteo las propiedades, es decir llamando a cada mesaje como #attenuation. Por lo regular uno setea los colaboradores sin hacer uso de los accessors dentro del #initialize. Pero en este caso, sino lo hago así me quedaría un #initialize más grande y más feo. Algo como: Light>>initialize "Initialize the receiver" super initialize. index := TV3DEnvironment current lightManager createDirectionalLightOfColor: self defaultColor direction: self defaultDirection. attenuation:= self defaultAttenuation. TV3DEnvironment current lightManager setLight: self index attenuation: attenuation ................ Que opinas ? saludos --- El mié 29-sep-10, GallegO <[email protected]> escribió: De: GallegO <[email protected]> Asunto: Re: [clubSmalltalk] Consulta sobre modelo Para: [email protected] Fecha: miércoles, 29 de septiembre de 2010, 14:49 Hola: Podrias usar algun objeto tipo TVEngineManager con una coleccion o variables o dict con cada uno de los engines instanciados. Incluslo a mismo implementas la finalizacion para que finalice los demas engines. De esa forma, si implementas un registro podes tener mas control sobre las interfaces instanciadas y de que manera vas haciendo los "release" ya que a veces no da buenos resultados (o no es posible) dejarlo librado a la logica de la finalizacion transparente por GC que proponen los frameworks COM. Saludos El 28 de septiembre de 2010 22:41, Jose Gregoris <[email protected]> escribió: Hola Tengo una duda sobre como modelar lo siguente. Tengo un COM llamado ITVLightEngine , que se encarga de crear luces y modificar todas las propiedades de las mismas. La interfase solo retorna un index a una luz y sobre eso quiero modelar un objeto Light. El tema es que ITVLightEngine es un singleton y todo lo que modifique sobre mi objeto Light debo hacerlo por medio de la interface. Si fuera una DLL no tendría dudas, ya que podría hacer algo así: Light>>color: aColor "Set the receiver color" color:= aColor. XXXDLL default setColor: aColor Aquí tengo un COM y hay que tenerlo instanciado. Podría tener una global y usarlo de la misma forma que una DLL. El tema es que esto se repite con unas cuantas interfases COM y no me gusta como queda con globales. Hay alguna forma estandar de modelar esto ? Tipo pattern Sugerencia ? saludos kiko -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
