Envoyé par
DonQuiche
Oui, on en a parlé. Si j'ai bien compris c'est seulement avec certains compilateurs, sur certaines plateformes, et c'est incompatible avec les bibliothèques existantes ?
Comme déjà dit, c'est actuellement pour Mobile (iOS/Android) et demain sur toutes les plateformes. Et non ce n'est pas incompatible, même s'il peut évidemment avoir des effets de bords de part le changement de cycle de vie des objets, Embarcadero - comme à l'époque de Delphi.Net - a fait en sorte que dans un cas classique le passage soit transparent.
Envoyé par
DonQuiche
Au temps pour moi. Tu peux donc, par exemple, utiliser ces informations pour générer à la volée un code pour dé-sérialiser un code JSON fourni par l'utilisateur ? Le tout avec un code raisonnable ?
Oui tu peux utiliser les RTTI pour cela, mais ce serait dommage de le faire toi même alors que c'est livré en standard.
Envoyé par
DonQuiche
Formidable, tu peux donc me montrer le code nécessaire pour sélectionner les trois étudiants mâles ayant obtenu les meilleures notes en mathématiques cette année ? Je parle d'objets en mémoire, pas dans la base de données. Ça tient en une ligne très compréhensible dans certains langages.
let students = from s in allStudents where s.isMale order by s.GetScore(Courses.maths, Year.current) take 3
Je n'ai aucun moyen d'écrire en une seule ligne de code Delphi ce que tu donnes là. Mais j'imagine que tu peux rendre cela paramétrable (et donc encore plus illisible) vu que j'ai rarement besoin d'extraire des données selon des critères fixes. Je voudrais la même chose avec le choix du sexe, de la matière et du nombre d'élément retournés...tu sais comme dans un cas réel en fait.
Envoyé par
DonQuiche
Et je ne parle pas seulement de les afficher, je parle de pouvoir faire des traitements sur eux. Et si tu trouves l'exemple absurde, je t'invite à faire une recherche de toutes tes boucles pour te demander combien consistent à cherche le(s) meilleur, calculer une moyenne, concaténer, transformer, etc. Autant d'opérations répétitives qui s'expriment bien mieux de façon fonctionnelle.
je suis totalement convaincu que ce n'est pas en réduisant la syntaxe à une seule ligne qu'on rend les choses plus robuste et facilement maintenable...mais j'attends l'exemple paramétré, ça m'intéresse.
Envoyé par
DonQuiche
Formidable, donc tu peux me montrer un tutoriel pour, par exemple, ajouter à ton modèle une méthode asynchrone renvoyant un futur que tu pourras attendre et auquel accrocher une continuation éventuelle ? Méthode qui contactera un service web à partir d'éléments passés en argument et, simultanément, cherchera dans un cache local si une copie existe ?
Voilà un exemple de pseudo-code dans un langage moderne :
1
2
3
4
| async Task<string> GetAnswerAsync(int id)
let result1 = await HttpHelper.DownloadString("http://someWeb.com/" + id)
let result2 = await File.ReadAsync("localCache/" + id + ".txt")
return await Task.Any(result1, result2) |
ça c'est totalement génial, c'est vrai que ça manque un "await" qui permet de rendre un code asynchrone synchrone, j'aime beaucoup le concept 
Envoyé par
DonQuiche
Clojure et Go mettent en oeuvre les CSP, Clojure, JRuby et Haskell offrent de la mémoire transactionelle, Rust et Go peuvent t'empêcher de partager des données par inadvertance, Erlang offre des acteurs isolés depuis quelques décennies, etc.
ça avec des concepts comme "await", on a besoin de garde fou
Envoyé par
DonQuiche
Il fête quand-même ses 55 ans cette année et beaucoup de ses fonctionnalités découlent du fait qu'on n'avait à l'époque que quelques kilooctets de mémoire. A commencer par ces immondes forward déclarations.
Tu n'as peut-être pas remarqué mais j'ai toujours utilisé "Delphi" quand tu parles du Pascal antique, Delphi n'a lui que 20 ans et son ancêtre directe c'est Turbo Pascal (Objet) qui n'a pas grand chose à voir avec le Pascal de Niklaus. Et je trouve ça très bien les forward.
Envoyé par
DonQuiche
Oui, parce qu'il a toujours eu le meilleur écosystème pour le web : c'était vrai à l'époque, c'est encore vrai aujourd'hui. Je déteste le php mais son succès n'est pas le fruit du hasard, quels que soient les torts du langage lui-même.
il est le fruit de quoi alors son succès ?
Par contre, je tiens à préciser tout de suite pour ceux qui seraient intéressés, il n'y a pas de "yield return"
Répondre avec citation
). Donner une tournure pédagogique à tes connaissances serait bénéfique à la fois pour les lecteurs (dont je ferai partie) mais aussi pour l'auteur qui se trouverait vite soumis à une certaine forme d'humilité. 
- Quelqu'un vous a aidé ou vous appréciez une intervention ? Pensez au 
Partager