- Pour qu'un langage/paradigme soit adopté, il faut entre autre, qu'il apporte quelque chose, j'ai du mal à résumer les avantages de ce que tu présentes! comment résumerais-tu cela toi?
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
- list_reapro : SET[PIECE] <-
(
+ result : SET[PIECE] := SET[PIECE].create; // on créé un ensemble de pièces
result := select refs from stock where qte<seuil // on liste les pièces
//stock est une collection d'objets pièces.
result // on les renvoient
);
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
- coupe_piste_selon_filtre_actif typefiltre : FILTRE volume_under volum : INTEGER <-
// ce header permet de couper toutes les pistes utilisant un filtre, dont le niveau sonore est en dessous de volum
(
// un filtre est un calcul effectué en temps réel sur flux son : equaliseur, disto
//phaser, etc...
+ list_soundagent : AGENT;
list_soundagent := select_agent from list_agent_playing where filtre_actif.type = typefiltre and volume<= volum;
list_soundagent.foreach {
x : AGENT;
x.mute;
};
);
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker