Je suis en train d'essayer d'en apprendre davantage et de tirer des leçons de la programmation fonctionnelle et de l'idée que l'immuabilité est bonne pour la concurrence, etc.
En guise d'exercice de réflexion, j'ai imaginé un jeu simple où un personnage de type Mario-esq peut courir et sauter autour d'ennemis qui lui tirent dessus...
J'ai ensuite essayé d'imaginer que cela pouvait être écrit de manière fonctionnelle en utilisant des objets immuables.
Cela a soulevé quelques questions qui m'ont laissé perplexe (étant un programmeur OO impératif).
1) Si mon petit bonhomme à la position x10,y100 se déplace d'une unité vers la droite, dois-je simplement le réinstaurer en utilisant ses anciennes valeurs avec un +1 à sa position x (par exemple x11,y100) ?
2) (Si ma première hypothèse est correcte) Si mon fil d'entrée déplace le petit bonhomme d'une unité vers la droite et que le fil d'IA ennemi tire sur le petit bonhomme et que le fil d'IA ennemi se résout avant le fil d'entrée, alors mon bonhomme perdra de la santé, puis lors de la résolution du fil d'entrée, la regagnera et se déplacera vers la droite ...
Est-ce que ça veut dire que je ne peux pas virer et oublier mes fils même avec l'immuabilité ? Dois-je envoyer mes threads pour qu'ils fassent leur truc puis mettre à jour le petit gars de manière synchrone lorsque j'ai les résultats des deux opérations threadées ? ou existe-t-il une solution simple et "fonctionnelle" ?
Il s'agit d'un problème d'enfilage légèrement différent de celui auquel je suis confronté au quotidien. En général, je dois décider si je me soucie de l'ordre dans lequel les fils sont résolus ou non. Dans le cas ci-dessus, techniquement, je ne me soucie pas de savoir s'il subit des dégâts ou se déplace en premier. Mais je me soucie de savoir si les conditions de course pendant l'instanciation causent la perte totale des données d'un thread.
3) (Encore une fois, si ma première hypothèse est correcte) Est-ce que l'instanciation constante de nouvelles instances d'un objet (par exemple Mario guy) a une surcharge horrible qui en fait une décision de conception très sérieuse/importante ?
EDITAR Désolé pour cette édition supplémentaire, je n'étais pas ce que la bonne pratique est ici sur les questions de suivi ...
4) Si l'immuabilité est quelque chose que je devrais rechercher et même sauter à travers des cerceaux d'instanciation de nouvelles versions d'objets qui ont changé... Et si j'instancie mon gars à chaque fois qu'il se déplace (seulement avec une position différente), n'ai-je pas exactement les mêmes problèmes que si il était mutable ? dans la mesure où quelque chose qui le référence à un moment donné regarde en fait d'anciennes valeurs ? Plus je creuse la question, plus j'ai la tête qui tourne, car générer de nouvelles versions de la même chose avec des valeurs différentes ressemble à de la mutabilité, via hack. :¬ ?
Je suppose que ma question est : comment devrait et en quoi est-ce plus avantageux que de simplement modifier sa position ?
for(ever)//simplified game-loop update or "tick" method
{
if(Keyboard.IsDown(Key.Right)
guy = new Guy(guy){location = new Point(guy.Location.x +1, guy.Location.y)};
}Aussi confus est : Le code ci-dessus signifie que le type est mutable ! (même si ses propriétés ne le sont pas)
4.5) Est-ce que c'est possible avec un type totalement immuable ?
Merci,
J.
