Question de niveau d'abstraction. Linq montre qu'on peut avoir des abstractions simples et puissantes.
Mais à l'origine on parlait de langage "hôte" et de langage "clients" histoire d'éviter les collisions de langage, genre garantir qu'une entrée utilisateur ne va pas injecter de SQL dans une requête construite en SQL. La nécessité pour garantir ça n'implique pas du tout qu'on perde en puissance dans l'expressivité de la dite requête construite en SQL résultante, "juste" qu'on soit capable d'assurer la traçabilité des données utilisateurs entre le moment où ce sont de simple chaînes de caractère et le moment ou on les fait basculer dans le monde du SQL. Et qu'au moment de cette bascule, on soit capable d'assurer que ces chaîne entrée utilisateurs ne vont pas se faire interpréter comme des bouts du langage client (SQL dans notre cas) et donc que l'escaping ait bien été effectué.
Ça n'implique pas du tout qu'on fasse perdre des moyens d'optimiser le SQL si on en reste là dans les principes. C'est uniquement parce que le problème est mal dévoupé et qu'on mélange différents niveau/problème qu'on peut perdre à certains autre niveau, ça n'implique pas du tout que ce soit une fatalité de l'abstraction de problème en soit. Au contraire en fait, souvent on abstrait certaines données du problème qui ne sont pas pertinentes pour ce qu'on veut résoudre pour séparer plus facilement les problèmes ...
Quand on dépend directement de l'interpréteur, c'est tout de même beaucoup moins souple si l'on souhaite étendre le système
Pardonne moi mais ça c'est encore une bêtise, tu as lu les papiers que cite https://linuxfr.org/news/tex-et-traitement-de-donnees-par-flot-e01-lire-du-tex ? Je te le conseille, tu verrais qu'il existe des langages dont les macros travaillent au niveau de la grammaire du langage de l'interpréteur, ce qui est un niveau d'abstraction assez élevé et pertinent, qui permettent d'offrir énormément de souplesse sans avoir à se battre avec l'interpréteur puisqu'il est prévu pour.
[^] # Re: Typage strict
Posté par thoasm . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2.
Question de niveau d'abstraction. Linq montre qu'on peut avoir des abstractions simples et puissantes.
Mais à l'origine on parlait de langage "hôte" et de langage "clients" histoire d'éviter les collisions de langage, genre garantir qu'une entrée utilisateur ne va pas injecter de SQL dans une requête construite en SQL. La nécessité pour garantir ça n'implique pas du tout qu'on perde en puissance dans l'expressivité de la dite requête construite en SQL résultante, "juste" qu'on soit capable d'assurer la traçabilité des données utilisateurs entre le moment où ce sont de simple chaînes de caractère et le moment ou on les fait basculer dans le monde du SQL. Et qu'au moment de cette bascule, on soit capable d'assurer que ces chaîne entrée utilisateurs ne vont pas se faire interpréter comme des bouts du langage client (SQL dans notre cas) et donc que l'escaping ait bien été effectué.
Ça n'implique pas du tout qu'on fasse perdre des moyens d'optimiser le SQL si on en reste là dans les principes. C'est uniquement parce que le problème est mal dévoupé et qu'on mélange différents niveau/problème qu'on peut perdre à certains autre niveau, ça n'implique pas du tout que ce soit une fatalité de l'abstraction de problème en soit. Au contraire en fait, souvent on abstrait certaines données du problème qui ne sont pas pertinentes pour ce qu'on veut résoudre pour séparer plus facilement les problèmes ...
Pardonne moi mais ça c'est encore une bêtise, tu as lu les papiers que cite https://linuxfr.org/news/tex-et-traitement-de-donnees-par-flot-e01-lire-du-tex ? Je te le conseille, tu verrais qu'il existe des langages dont les macros travaillent au niveau de la grammaire du langage de l'interpréteur, ce qui est un niveau d'abstraction assez élevé et pertinent, qui permettent d'offrir énormément de souplesse sans avoir à se battre avec l'interpréteur puisqu'il est prévu pour.