[Jde-dev] struct varcolor

[David Lobato]

A ver que os parece esto:

Mantenemos los nombres Encoders,Motors,Varcolor,... para los tipos de
datos de cada sensor/actuador tal y como está ahora.

Para acceder a ellos desde diferentes esquemas, estoy programando algo
parecido a un proxy, que hace el acceso igual tanto para el que
implementa el interfaz como para el que lo usa. Por ello veo lógico
llamar a dichos tipos igual que el sensor/actuador mas el sufijo Prx
(en ICE usan una nomenclatura similar), de modo que tendríamos:

Encoders y EncodersPrx
Motors y MotorsPrx
...


La idea es que el esquema que implementa el interfaz tiene los datos y
los que lo usan acceden a ellos desde el proxy.
Todo esto se traduce posteriormente en llamadas a myexport/myimport.

Yo creo que queda claro, ¿no?
¿Cómo lo véis?


2009/6/10 David Lobato <dav.lobato en gmail.com>:
> A ver, estoy con el tema de nombrado para los interfaces y lo que
> propuso José María me parece demasiado largo. Por ejemplo en el caso
> de Encoders, quedaría así:
>
> Para el tipo:
> Encoders_Interface
>
> Y las funciones asociadas:
> new_EncodersI
> Encoders_Interface_<member>_set
> Encoders_Interface_<member>_get
> Encoders_Interface_run
>
> ....
>
>
> ¿Cómo lo véis? ¿Propuestas?
>
>
> 2009/6/9 David Lobato <dav.lobato en gmail.com>:
>> Lo cierto es que es tan sólo un asunto de nombres, ni si quiera de diseño...
>> Así que para no romper nada, mantengo los nombres actuales y pongo
>> nuevos a lo que yo vaya añadiendo.
>>
>> Saludetes,
>> David.
>>
>> 2009/6/9 Roberto Calvo <rocapal en gsyc.es>:
>>>
>>> El tener un buen diseño va un poco en contra de mantener la
>>> compatibilidad. Creo que debemos tener mucho cuidado y tener contentos a
>>> nuestros usuarios, esto es, mantener la compatibilidad.
>>>
>>> Si sacamos al versión 4.3.2 y ello conlleva que la gente cambie sus
>>> esquemas ... no estamos haciendo las cosas bien.
>>>
>>> Tenemos momentos en los que si somos conscientes que podemos realizar
>>> cambios en el diseño (como hemos tenido con la 4.3). Y asumimos el coste
>>> y esfuerzo del usuario por cambiar su código.
>>>
>>> En resumen, todo lo que nos lleve a no ser compatible con la 4.3.0 lo
>>> veo perjudicial para nosotros (y más para los usuarios de jderobot).
>>> Quizás podemos solucionar éste o cualquier otro problema de una manera
>>> no tan "brillante", pero ya tendremos la oportunidad de cambiar lo que
>>> veamos en la 5.0.
>>>
>>> En general, deberíamos tender siempre a ser lo más compatible posible
>>> hacía atrás.
>>>
>>> un saludo!
>>>
>>> El lun, 08-06-2009 a las 17:44 +0200, JoseMaria escribió:
>>>> uhm... preferiría no retocar los nombres actuales para no obligar a los
>>>> usuarios a modificar su código fuente. También veo la necesidad de usar
>>>> nombres diferentes para cosas que son distintas: los datos del interfaz
>>>> y el propio tipo del interfaz.
>>>>
>>>> Una solución que mantiene compatibilidad con lo existente y permite
>>>> nombrar a ambas cosas es (1) reservar los nombres actuales para los
>>>> datos y (2) crear los nombres varcolor_interface, motors_interface,
>>>> encoders_interface, etc para designar a los tipos de interfaces. Este
>>>> sencillo convenio permite nombrar los tipos de los interfaces y todos se
>>>> tratan exactamente igual.
>>>>
>>>> ¿Cómo lo veis?
>>>>
>>>> JoseMaria
>>>> On Fri, 2009-05-15 at 11:55 +0200, David Lobato wrote:
>>>> > Buenos días,
>>>> >
>>>> > estoy liado con el interfaz varcolor y me surge una cuestión.
>>>> > En los interfaces que ya he implementado (encoders,laser y motors) la
>>>> > estructura que guarda los datos se llama <interfaz>_data, reservando
>>>> > el nombre <interfaz> para el tipo que propiamente define el interfaz.
>>>> > Pongo un ejemplo que os veo las caras:
>>>> >
>>>> > typedef struct{
>>>> >   /*perceptions*/
>>>> >   float robot[ROBOT_NELEM];
>>>> >   unsigned long int clock;
>>>> >   /*modulations*/
>>>> >   int cycle;
>>>> > } Encoders_data;
>>>> >
>>>> > typedef Interface Encoders;
>>>> >
>>>> > Sin entrar de momento en mas detalles, la cuestión es que tengo que
>>>> > cambiar el nombre de la estructura Varcolor por Varcolor_data, para
>>>> > que siga el mismo criterio.
>>>> > ¿Véis algún problema (a parte de tener que sustituir en unos cuantos sitios)?
>>>> >
>>>> >
>>>> > Un saludete.
>>>> > David.
>>>> > _______________________________________________
>>>> > Jde-developers mailing list
>>>> > Jde-developers en gsyc.es
>>>> > http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>> --
>>> Roberto Calvo Palomino          | Libre Software Engineering Lab (GSyC)
>>> Tel: (+34) 91 488 85 23         | Universidad Rey Juan Carlos
>>> Tel: (+34) 91 488 81 05         | Edif. Departamental II - Despacho 116
>>> rocapal en gsyc.es                 | c/Tulipán s/n 28933 Móstoles (Madrid)
>>> http://libresoft.es/
>>>
>>> GPG-KEY: http://gsyc.es/~rocapal/rocapal.gpg
>>>
>>
>