Un objet actif c'est masquer derrière un proxy ayant une sémantique orientée objet quelque chose qui ne l'est
pas du tout (appel de méthode local synchrone VS dispatch distant asynchrone).
Ben euh, non: un objet c'est l'encapsulation d'un état local et des fonctions qui permettent de faire évoluer cet état. Que ça soit mis en oeuvre avec des classes et des méthodes plutôt que des threads et des fonctions ne change pas grand chose à l'affaire.
Dans un langage comme erlang (ou erlang tout court, je ne connais pas vraiment d'équivalent), l'absence de sémaphores, états globaux et autres c***ies du genre, autorisent une telle optimisation du runtime qu'il n'est pas déconnant de concevoir une application avec un objet = un thread.
C'est très vendeur sur les hello
world mais en pratique c'est une leaky abstraction immonde qui empêche de designer correctement son application
et de gérer les cas d'erreurs.
Justement pas, comme cité par un autre commentaire, un objet actif est la plupart du temps assez indépendant pour pouvoir crasher et redémarrer sans embêter les autres.
C'est grosso modo le même problème que les systèmes de type RPC, connu depuis très longtemps mais après 20 ans
on arrive toujours au même conclusion.
Des précisions ?
Un modèle à objet actif, je veux bien au sein d'un unique processus mais ça me semble un mauvais compromis, vu
que t'as le pire de deux mondes entre un truc mono-process bien designé qui va vite et une abstraction solide
pour exprimer du parallélisme potentiellement distribué.
[Note: vision biaisée d'un ex-mainteneur d'un framework à objet actifs...]
[Note: vision biaisée d'un développeur heureux qui a finalement trouvé erlang après des années sus des systèmes distribués qui finissent tous par devenir complètement ingérables et/ou pas scalables du tout]
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Retour sur les objets actifs
Posté par Jean Parpaillon . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 5.
Ben euh, non: un objet c'est l'encapsulation d'un état local et des fonctions qui permettent de faire évoluer cet état. Que ça soit mis en oeuvre avec des classes et des méthodes plutôt que des threads et des fonctions ne change pas grand chose à l'affaire.
Dans un langage comme erlang (ou erlang tout court, je ne connais pas vraiment d'équivalent), l'absence de sémaphores, états globaux et autres c***ies du genre, autorisent une telle optimisation du runtime qu'il n'est pas déconnant de concevoir une application avec un objet = un thread.
cf. https://www.sics.se/~joe/ericsson/du98024.html ou http://www.lshift.net/blog/2006/09/10/erlang-processes-vs-java-threads/
Justement pas, comme cité par un autre commentaire, un objet actif est la plupart du temps assez indépendant pour pouvoir crasher et redémarrer sans embêter les autres.
Des précisions ?
[Note: vision biaisée d'un développeur heureux qui a finalement trouvé erlang après des années sus des systèmes distribués qui finissent tous par devenir complètement ingérables et/ou pas scalables du tout]
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier