Consulta sobre modelo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Consulta sobre modelo

Jose Gregoris
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Sebastian Calvo
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 <[hidden email]> 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Jose Gregoris
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 <[hidden email]> escribió:

De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [hidden email]
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 <kikodelphi@...> 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 clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Sebastian Calvo
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 <[hidden email]> 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 <[hidden email]> escribió:

De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [hidden email]
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 <kikodelphi@...> 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 clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Dolphin - Nuevo sitio , nuevo precio

BrunoBB

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

 

El sitio quedo muy bueno !

 

Saludos,

Bruno

 

 

De: [hidden email] [mailto:[hidden email]] En nombre de GallegO
Enviado el: Thursday, September 30, 2010 9:33 AM
Para: [hidden email]
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 <[hidden email]> 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 <[hidden email]> escribió:


De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [hidden email]
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 <kikodelphi@...> 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 clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org


 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Dolphin - Nuevo sitio , nuevo precio

Alejandro Pérez
Pero sigue siendo la versión 6, ¿no? ¿Se sabe algo de la NG?

Saludos.



2010/9/30 Smalltalk <[hidden email]>

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

 

El sitio quedo muy bueno !

 

Saludos,

Bruno

 

 


--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Dolphin - Nuevo sitio , nuevo precio

Alexandre Bergel-5
In reply to this post by BrunoBB
> http://www.object-arts.com/
>  
> El sitio quedo muy bueno !

Sipo!

Alexandre

>
>  
>  
> De: [hidden email] [mailto:[hidden email]] En nombre de GallegO
> Enviado el: Thursday, September 30, 2010 9:33 AM
> Para: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]> escribió:
>
> De: GallegO <[hidden email]>
> Asunto: Re: [clubSmalltalk] Consulta sobre modelo
> Para: [hidden email]
> 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 <[hidden email]> 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 [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>  
> http://www.clubSmalltalk.org
>  
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>  
> http://www.clubSmalltalk.org
>
>  
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>  
> http://www.clubSmalltalk.org
>  
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>  
> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>  
> http://www.clubSmalltalk.org

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Jose Gregoris
In reply to this post by Sebastian Calvo
Hola Gallego

Sin hacer mucho laburo yo sacaria de los accessors a i.v. la llamada al componente.

Este es el principal problema a mi entender.
Los objetos se modifican por medio de un browser similar a lo que es el PublishedAspectInspector.
Si saco de los accessors la llamada al componente,  se me complica la actualización del componente.
El objeto quedaría actualizado, pero no la interfase.

Como manejarias la actualizacion en este caso ?

Tendría que tener algo del estilo:

>>color: aColor

color:= aColor.
self update.

En este caso debería actualizar todas la propiedades, de manera innecesaria, a menos que le pase algo al #update tipo un símbolo y haga un #perform de la propiedad adecuada.

Estaba  viendo algo en Dolphin:

AXControlSite>>isDesignMode: aBoolean
    "Set whether the control is in design mode or not."

    hostFlags := hostFlags mask: UserModeMask set: aBoolean not.
    self ambientDispatch userMode: aBoolean not

IAxWinAmbientDispatch>>userMode: pbUserMode
    "Set the 'UserMode' property of the receiver to the <varbool> value of the argument.
    Helpstring: Set the ambient user mode"

    self put_UserMode: pbUserMode


Es basicamente lo que hago yo.
Por otra parte, esto es algo en C# que encontré por casualidad

namespace CMEngine
{
public class Actor
{
private TVActor mActor;
private TVPath mPath;
private float mPathSpeed;
private int mAnimationID;
private CONST_TV_ACTORMODE mActorMode;
private CONST_TV_LIGHTINGMODE mLightingMode;
private CONST_TV_CULLING mCullMode;
private bool mCollisionEnable;
private bool mAnimationLoop;
private string mAnimationByName;
private bool mAlphaTest;
private TVShader mShader;
private CONST_TV_BLENDINGMODE mBlendingMode;
private int mColor;
private int mBlendedAnimationID;
private string mBlendedAnimationByName;
private float mBlendedAnimationWeight;
private bool mBlendedAnimationLoop;


public TVPath Path
{
get
{
return mPath;
}
set
{
mPath = value;
mActor.SetPath(value);
}
}

.........

 


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.


Acá no me queda claro.
Estarías haciendo algo así:

|aLight|
aLight:=Light new
aLight create.

Las interfases no son serializables y supone un problema adicional.
Yo grabe en formato binario y luego implemente un #reinitialize, donde se crea la interfase usando los valores que tenía el objeto..

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.

Eso de los default lo saque de Smalltalk Best prectice.
La opción del pattern no me queda clara, estuve viendo y no le encuentro la aplicación.
 
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.

Entiendo para la instanciación, pero no para la actualización como te comentaba arriba

Saludos y gracias kiko

--- El jue 30-sep-10, GallegO <[hidden email]> escribió:

De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [hidden email]
Fecha: jueves, 30 de septiembre de 2010, 9:32

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 <kikodelphi@...> 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 <fxgallego@...> escribió:

De: GallegO <fxgallego@...>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: clubsmalltalk@...
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 <kikodelphi@...> 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 clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Sebastian Calvo
Kiko:



Este es el principal problema a mi entender.
Los objetos se modifican por medio de un browser similar a lo que es el PublishedAspectInspector.
Si saco de los accessors la llamada al componente,  se me complica la actualización del componente.
El objeto quedaría actualizado, pero no la interfase.

Podes poner un update o podes marcar esos objetos como immutables entonces redefinis #errorInstVarAt:put: para que envien el update. Incluso podes saber qué propiedad fue la que cambio. 

 
Estaba  viendo algo en Dolphin:

AXControlSite>>isDesignMode: aBoolean
    "Set whether the control is in design mode or not."

    hostFlags := hostFlags mask: UserModeMask set: aBoolean not.
    self ambientDispatch userMode: aBoolean not


Ok. Si son unos pocos mensajes no hay problema. Lo tuyo es otra cosa.

 
IAxWinAmbientDispatch>>userMode: pbUserMode
    "Set the 'UserMode' property of the receiver to the <varbool> value of the argument.
    Helpstring: Set the ambient user mode"

    self put_UserMode: pbUserMode

Aca usa algo como lo que te decia, delega en otro mensaje que implementa el contacto con la interfaz. Si implementas todo eso con un visitor luego es mas facil cambiar el engine que hace el render, podes tener distintos engines sin que el modelo se entere quien lo renderea. 
 
Es basicamente lo que hago yo.
Por otra parte, esto es algo en C# que encontré por casualidad

Puede ser un ejemplo "corto". Funciona pero a la larga es problematico implementar un setter que haga algo más que setear. Incluso a veces algo tan estupido como triggerear #changed en el setter es algo para tener en cuenta por temas de perfomance al instanciar miles de objetos.
La otra es:

light: aLight
  self basicLight: aLight.
  self engine light: aLight


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.


Acá no me queda claro.
Estarías haciendo algo así:

|aLight|
aLight:=Light new
aLight create.

Las interfases no son serializables y supone un problema adicional.
Yo grabe en formato binario y luego implemente un #reinitialize, donde se crea la interfase usando los valores que tenía el objeto..


initialize
  super initialize.
  light := Light new

render
  super render.
  self renderLight

 
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.

Eso de los default lo saque de Smalltalk Best prectice.

Bueno, debe estar bien entonces. A mi no me gusta, sobre todo si es al pedo.
 
La opción del pattern no me queda clara, estuve viendo y no le encuentro la aplicación.
 
Tiene mas aplicacion cuando hay cosas que pueden o no estar en el modelo, es decir lo decoran. Por ejemplo si tenes que dibujar una linea, en vez de tener propiedades que te indiquen si deben dibujar el from con un determinado cap o el fin con otro podes agregarle al objeto linea a su coleccion de decorations que debe dibujar un startCap y un endCap con determinado estilo.


 
 
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.

Entiendo para la instanciación, pero no para la actualización como te comentaba arriba


Hay distintas formas de resolverlo. Yo no lo dejaria atado al los setters.
No se que opinaran los demas, o Kent Beck jeje ya no tengo el libro en el baño :(
 
Saludos y gracias kiko


Saludos
 
--- El jue 30-sep-10, GallegO <[hidden email]> escribió:

De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [hidden email]
Fecha: jueves, 30 de septiembre de 2010, 9:32


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 <kikodelphi@...> 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 <fxgallego@...> escribió:

De: GallegO <fxgallego@...>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: clubsmalltalk@...
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 <kikodelphi@...> 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 clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Jose Gregoris

Hola Gallego

Lo de Visitor esta claro, pero por el momento no me la quiero complicar.
Solo quiero hacer lo que comentaba , de la  mejor  forma y más clara   posible.

Podes poner un update o podes marcar esos objetos como immutables entonces redefinis #errorInstVarAt:put: para que envien el update. Incluso podes saber qué propiedad fue la que cambio. 


Que ventajas me da esto ? Sobre solo poner un #update: y mandar un simbolo para ejecutar luego con sus argumentos.

La otra es:
light: aLight
  self basicLight: aLight.
  self engine light: aLight

Que diferencia o ventaja tiene con poner el setter de una ?
O es solo por cuestión de claridad ?

Eso de los default lo saque de Smalltalk Best prectice.

Bueno, debe estar bien entonces. A mi no me gusta, sobre todo si es al pedo.


jajaja si entiendo , no era para desautorizar tu comentario, solo para decir de donde salió

saludos kiko


--- El vie 1-oct-10, GallegO <[hidden email]> escribió:

De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [hidden email]
Fecha: viernes, 1 de octubre de 2010, 11:01

Kiko:



Este es el principal problema a mi entender.
Los objetos se modifican por medio de un browser similar a lo que es el PublishedAspectInspector.
Si saco de los accessors la llamada al componente,  se me complica la actualización del componente.
El objeto quedaría actualizado, pero no la interfase.

Podes poner un update o podes marcar esos objetos como immutables entonces redefinis #errorInstVarAt:put: para que envien el update. Incluso podes saber qué propiedad fue la que cambio. 

 
Estaba  viendo algo en Dolphin:

AXControlSite>>isDesignMode: aBoolean
    "Set whether the control is in design mode or not."

    hostFlags := hostFlags mask: UserModeMask set: aBoolean not.
    self ambientDispatch userMode: aBoolean not


Ok. Si son unos pocos mensajes no hay problema. Lo tuyo es otra cosa.

 
IAxWinAmbientDispatch>>userMode: pbUserMode
    "Set the 'UserMode' property of the receiver to the <varbool> value of the argument.
    Helpstring: Set the ambient user mode"

    self put_UserMode: pbUserMode

Aca usa algo como lo que te decia, delega en otro mensaje que implementa el contacto con la interfaz. Si implementas todo eso con un visitor luego es mas facil cambiar el engine que hace el render, podes tener distintos engines sin que el modelo se entere quien lo renderea. 
 
Es basicamente lo que hago yo.
Por otra parte, esto es algo en C# que encontré por casualidad

Puede ser un ejemplo "corto". Funciona pero a la larga es problematico implementar un setter que haga algo más que setear. Incluso a veces algo tan estupido como triggerear #changed en el setter es algo para tener en cuenta por temas de perfomance al instanciar miles de objetos.
La otra es:

light: aLight
  self basicLight: aLight.
  self engine light: aLight


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.


Acá no me queda claro.
Estarías haciendo algo así:

|aLight|
aLight:=Light new
aLight create.

Las interfases no son serializables y supone un problema adicional.
Yo grabe en formato binario y luego implemente un #reinitialize, donde se crea la interfase usando los valores que tenía el objeto..


initialize
  super initialize.
  light := Light new

render
  super render.
  self renderLight

 
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.

Eso de los default lo saque de Smalltalk Best prectice.

Bueno, debe estar bien entonces. A mi no me gusta, sobre todo si es al pedo.
 
La opción del pattern no me queda clara, estuve viendo y no le encuentro la aplicación.
 
Tiene mas aplicacion cuando hay cosas que pueden o no estar en el modelo, es decir lo decoran. Por ejemplo si tenes que dibujar una linea, en vez de tener propiedades que te indiquen si deben dibujar el from con un determinado cap o el fin con otro podes agregarle al objeto linea a su coleccion de decorations que debe dibujar un startCap y un endCap con determinado estilo.


 
 
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.

Entiendo para la instanciación, pero no para la actualización como te comentaba arriba


Hay distintas formas de resolverlo. Yo no lo dejaria atado al los setters.
No se que opinaran los demas, o Kent Beck jeje ya no tengo el libro en el baño :(
 
Saludos y gracias kiko


Saludos
 
--- El jue 30-sep-10, GallegO <fxgallego@...> escribió:

De: GallegO <fxgallego@...>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: clubsmalltalk@...
Fecha: jueves, 30 de septiembre de 2010, 9:32


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 <kikodelphi@...> 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 <fxgallego@...> escribió:

De: GallegO <fxgallego@...>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: clubsmalltalk@...
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 <kikodelphi@...> 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 clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Consulta sobre modelo

Sebastian Calvo
Podes poner un update o podes marcar esos objetos como immutables entonces redefinis #errorInstVarAt:put: para que envien el update. Incluso podes saber qué propiedad fue la que cambio. 


Que ventajas me da esto ? Sobre solo poner un #update: y mandar un simbolo para ejecutar luego con sus argumentos.


La unica ventaja es que no tenes que hacer nada... aunque por otro lado, luego, dependes de Dolphin ya que no todos los Smalltalk soportan eso.

 

La otra es:
light: aLight
  self basicLight: aLight.
  self engine light: aLight

Que diferencia o ventaja tiene con poner el setter de una ?
O es solo por cuestión de claridad ?


Y, si queres setear la i.v light sin hacer mas nada que eso tenes que tener un metodo que setee solamente, #basicLight: y de ahi hacemos que ese solo sea el que lee / escribe la i.v.
De todas formas no es un patron que este bueno, es simplemente un "parche" para salvar tu caso y puntualmente te lo señalo ya que en esos setters estarias poniendo una dependencia muy grosa con un componente externo, algo que no tiene que ver mucho con el modelo.
 
Eso de los default lo saque de Smalltalk Best prectice.

Bueno, debe estar bien entonces. A mi no me gusta, sobre todo si es al pedo.


jajaja si entiendo , no era para desautorizar tu comentario, solo para decir de donde salió

saludos kiko


Si, y yo te digo en serio, quizas este bien. Yo siempre explico desde mi ignorancia, intuicion personal y experiencia :)


Saludos

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org