Concernant le GC je me suis sans doute mal exprimé, je ne suis pas contre, tout au contraire... mais dans ma vision des choses, ce n'est pas une façon "de ne plus devoir gérer la mémoire", juste une façon différente de gérer les choses... ça a des avantages (éviter pas mal de bug, rendre les choses plus simples, parfois plus intuitives, etc...) mais aussi des inconvénients (généralement on consomme plus de mémoire, parfois énormément plus parce qu'on ne réalise pas ce qui se passe derrière).
"C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors."
Peut-être un problème lié à l'utilisation de java? (genre dit rapidement: un design de m... :p).
Ce que je constate de mon côté: non tous le monde ne connait pas SQL! c'est même plutôt le contraire, il est très difficile de trouver quelqu'un de compétent en SQL!
En effet, la plupart des informaticiens peuvent te faire un "select * from news", en connais-tu bcp capable de t'estimer le temps d'exécution d'une requete, de te dire que select * from test where A=B and B=C est plus ou moins effaice que select * from test where C=B and B=A? de déterminer qu'il est temps de splitter la table parce que tu gagneras X % en perf?
Pas plus tard qu'hier, j'ai encore vu un développeur retourner l'ensemble des enregistrement d'une table, pour n'en prendre qu'un subset à afficher à l'écran! (typiquement ce qui me fait peur à intégrer le SQL dans le langage: on en aurait partout, et il serait difficile voir impossible de déterminer facilement SGBD, XML, mémoire, etc..).
"Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple."
foreach(Cruiser c in Team){
if(c.Dist(this) < 400) c.SendMessage("kikoo");
}
tu pourrais même imaginer, si la distance revient souvent faire un:
foreach(Cruiser c in TeamRange(400) c.SendMessage("kikoo");
ton exemple de distance est intéressant c'est exactement le genre de chose qui n'est pas toujours efficace en SQL.
"Mais tout d'abord il faut commencer par le compilateur."
J'ai du mal à comprendre ton approche, tu veux un compilo avant de définir comment tu vas t'en servir, j'ai tendance à penser dans l'autre sens... on arrivera pas à s'entendre là dessus :p Je suis troublé par ton article, il utilise un vocabulaire qui me fait penser à un papier universitaire, mais ta motivation semble très pragmatique, du genre "ça me fait chier de faire 30 lignes quand 2 suffiraient".
"D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe."
Un delegate c'est un sucre syntaxique te permettant d'appeler une méthode d'un objet depuis de façon dynamique (c'est donc le couple "signature de la méthode" et instance de l'objet, en C++ on a les pointeurs vers des méthodes, mais ça marche mal, là l'idée est là même mais c'est fortement typé, en java, c'est en gérénal le couple classe anonyme interface qui fait cela).
Je trouve l'explication sur developpez.com mauvaise... en effet ça fait bricolage! De plus c'est du mauvais code! (ça sert à quoi son truc affreux? à part montrer que c'est un design dégueu??? j'adore vraimetn ce site :p).
Les cas d'utilisation les plus courant des delegates sont: gérer les évènement (je veux appeler la méthode "toto" de ma classe quand l'utilisateur clique sur un bouton") et tout ce qui est callback.
Enfin, une suggestion as-tu déjà penser implémenter tes idées (hors sucre syntaxiques) dans un langage, voir comment cela se comporte?
[^] # Re: Pas tout compris
Posté par tene . En réponse au journal Le langage de mes rêves. Évalué à 2.
Concernant C# je t'invite à regarder: http://msdn.microsoft.com/vcsharp/future/linqsamples/ le sucre syntaxique est plus évolué.
Concernant le GC je me suis sans doute mal exprimé, je ne suis pas contre, tout au contraire... mais dans ma vision des choses, ce n'est pas une façon "de ne plus devoir gérer la mémoire", juste une façon différente de gérer les choses... ça a des avantages (éviter pas mal de bug, rendre les choses plus simples, parfois plus intuitives, etc...) mais aussi des inconvénients (généralement on consomme plus de mémoire, parfois énormément plus parce qu'on ne réalise pas ce qui se passe derrière).
"C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors."
Peut-être un problème lié à l'utilisation de java? (genre dit rapidement: un design de m... :p).
Ce que je constate de mon côté: non tous le monde ne connait pas SQL! c'est même plutôt le contraire, il est très difficile de trouver quelqu'un de compétent en SQL!
En effet, la plupart des informaticiens peuvent te faire un "select * from news", en connais-tu bcp capable de t'estimer le temps d'exécution d'une requete, de te dire que select * from test where A=B and B=C est plus ou moins effaice que select * from test where C=B and B=A? de déterminer qu'il est temps de splitter la table parce que tu gagneras X % en perf?
Pas plus tard qu'hier, j'ai encore vu un développeur retourner l'ensemble des enregistrement d'une table, pour n'en prendre qu'un subset à afficher à l'écran! (typiquement ce qui me fait peur à intégrer le SQL dans le langage: on en aurait partout, et il serait difficile voir impossible de déterminer facilement SGBD, XML, mémoire, etc..).
"Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple."
foreach(Cruiser c in Team){
if(c.Dist(this) < 400) c.SendMessage("kikoo");
}
tu pourrais même imaginer, si la distance revient souvent faire un:
foreach(Cruiser c in TeamRange(400) c.SendMessage("kikoo");
ton exemple de distance est intéressant c'est exactement le genre de chose qui n'est pas toujours efficace en SQL.
"Mais tout d'abord il faut commencer par le compilateur."
J'ai du mal à comprendre ton approche, tu veux un compilo avant de définir comment tu vas t'en servir, j'ai tendance à penser dans l'autre sens... on arrivera pas à s'entendre là dessus :p Je suis troublé par ton article, il utilise un vocabulaire qui me fait penser à un papier universitaire, mais ta motivation semble très pragmatique, du genre "ça me fait chier de faire 30 lignes quand 2 suffiraient".
"D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe."
Un delegate c'est un sucre syntaxique te permettant d'appeler une méthode d'un objet depuis de façon dynamique (c'est donc le couple "signature de la méthode" et instance de l'objet, en C++ on a les pointeurs vers des méthodes, mais ça marche mal, là l'idée est là même mais c'est fortement typé, en java, c'est en gérénal le couple classe anonyme interface qui fait cela).
Je trouve l'explication sur developpez.com mauvaise... en effet ça fait bricolage! De plus c'est du mauvais code! (ça sert à quoi son truc affreux? à part montrer que c'est un design dégueu??? j'adore vraimetn ce site :p).
Les cas d'utilisation les plus courant des delegates sont: gérer les évènement (je veux appeler la méthode "toto" de ma classe quand l'utilisateur clique sur un bouton") et tout ce qui est callback.
Enfin, une suggestion as-tu déjà penser implémenter tes idées (hors sucre syntaxiques) dans un langage, voir comment cela se comporte?