Salut Une question qu'on a soulevé a la derniere séance codage et qu'on a legerement évitée. On avait fait un joli travail de normalisation pour les drivers et je me demande si ca peut rester d'actualité avec la nouvelle architecture.
personnellement, je trouve pas mal d'avoir des methodes un peu haut niveau (style On/Off ) au niveau du bus client, que ce soit pour les actuator/sensors, ou pour les reguls etc vu qu'on a mis un peut tout a plat sur le meme niveau, j'ai du mal a envisager comment on pourrais forcer la normalisation niveau driver et autoriser une pareille souplesse pour les autres.
Le principal probleme,il me semble, est de pouvoir garder un peut de souplesse tout en evitant que ce soit la foire. Le read est le write coté drivers permetait d'assurer en quelque sorte une compatibilité entre les différents composants pour méthodes ayant des fonctionnalité similaires.
Le truc que je me dis c'est qu'on peut toujours dire aux types qui codent "essayez de n'utiliser que du read et du write", mais a mon avis ca ne sera pas suffisant et rien n’empêchera un type de coder un driver ou un autre composants avec une methode qui sort des clou, et qui ne sera plus compatible avec les autres composants.
La ou ca part en cacahouète c'est pour le passage d'arguments. Le
probleme ne se présentait pas directement pour l'ancienne archi car
toute les méthode ayant des nom bizarres n'avais jamais d'arguments a
passer et donc les clients n'avais pas trop de question a se poser.
donc je ne sais pas trop ce que tu en pense, mais il faudrait trouver un truc pour eviter que ce soit la merde. moi j'envisage deux pistes (aucune des deux ne me plais vraiment)
n'autoriser les methodes exotiques que pour les composants qui sont mappé avec un objet terminal.
n'autoriser les méthodes exotiques que si elle n'ont pas d'argument a passer, pour les autres il y a le read et le write.