http://www.object-arts.com/

 

El sitio quedo muy bueno !

 

Saludos,

Bruno

 

 

De: [email protected] [mailto:[email protected]]
En nombre de GallegO
Enviado el: Thursday, September 30, 2010 9:33 AM
Para: [email protected]
Asunto: Re: [clubSmalltalk] Consulta sobre modelo

 

Hola:

 

Sin hacer mucho laburo yo sacaria de los accessors a i.v. la llamada al
componente. Tambien removeria todas las sucesivas llamadas a las globales
por un metodo implementado en la superclase que devuelva la interfaz.
Incluso eso puede hacer un lookup dinamico de la interfaz mas apropiada
partiendo del nombre de la clase donde es solicitada.

 

El initialize lo dejaria que setee las propiedades basicas sin hacer el
render o creacion efectiva en la interfaz hasta que yo se lo diga. Imaginate
que esto es util al momento de recrear todo el modelo, por ejemplo podrias
grabar el image con el modelo instanciado, salir volver a entrar y que todo
se encuentre como antes sin mucho esfuerzo.

 

Todos los defaultXxxx, si te gusta dejalos. Yo prefiero no poner tanta cosa
si no hace falta, es decir, cuando la probabilidad de redefinir esos metodos
en subclases es infima, entonces tener un #defaultXxx para cada default me
parece que no es necesario. Fijate. Hay otra opcion que es tener una
coleccion de decorators, fijate el pattern Decorator.

 

Los metodos que hacen contacto con la interfaz los pondria en otra familia,
por ejemplo #setAttenuation: o como mas te guste.

A estos QUIZAS los llamaria desde un metodo #create o #render o algo asi.

 

Tambien podria usarse un pattern visitor. Para mi el visitor es más elegante
y la verdad en distintos usos siempre nos dio buenos resultados, pero, a
veces siento que me aleja un poco de lo que quiero hacer realmente en ese
momento.Quizas es la opcion a implementar para refinar la cosa una vez que
tenes claro como debería andar.

De todas formas no estoy seguro si para tu problema aplica ese pattern o
conviene otra cosa.

 

Espero que alguien ayude si sabe más.

 

Saludos

 GAllegO

 

El 29 de septiembre de 2010 15:51, Jose Gregoris <[email protected]>
escribió:


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]
<http://mc/[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]
<http://mc/[email protected]> 
To unsubscribe from this group, send email to
[email protected]
<http://mc/compose?to=clubsmalltalk%[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]
<mailto:clubsmalltalk%[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]
<mailto:clubsmalltalk%[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

Responder a