Question de niveau d'abstraction. Linq montre qu'on peut avoir des abstractions simples et puissantes.
Puissance limitée tout de même : LINQ ne gère pas, par exemple, les requêtes récursives en SQL. Donc il va falloir contourner un problème qui n'a aucune raison d'exister si par malheur tu en as besoin. Pour cela et pour les raisons évoquées précédemment ce n'est certainement pas la solution universelle.
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.
Euh oui enfin c'est tout de même toi qui est venu avec LINQ pour exemple et qui propose justement de se débarrasser complètement de la query string SQL pour régler ce problème.
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 ...
Le problème est bien là : entre ajouter une petite fonction native gérant un sprintf et du safe_escape sur des données typées pour finalement les insérer là où tu veux dans une query string et une intégration au langage comme LINQ il y a un monde et il n'est pas évident de savoir où tu mets le curseur pour définir ce fameux système de sécurisation des requêtes universel qui conviendra à tous les usages.
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.
Mes propos concernaient là encore les manques de LINQ, maintenant tu viens me parler de Tex...
De quelle façon tu comptes te servir concrètement d'un tel système pour gérer la problématique évoquée ?
Je ne suis d'ailleurs pas non plus convaincu, à la base, qu'il soit si pertinent de vouloir mixer deux choses très différentes : un langage de programmation et un langage de requête dans une syntaxe commune qui n'exprime pas clairement ce qui sera envoyé au serveur.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2.
Puissance limitée tout de même : LINQ ne gère pas, par exemple, les requêtes récursives en SQL. Donc il va falloir contourner un problème qui n'a aucune raison d'exister si par malheur tu en as besoin. Pour cela et pour les raisons évoquées précédemment ce n'est certainement pas la solution universelle.
Euh oui enfin c'est tout de même toi qui est venu avec LINQ pour exemple et qui propose justement de se débarrasser complètement de la query string SQL pour régler ce problème.
Le problème est bien là : entre ajouter une petite fonction native gérant un sprintf et du safe_escape sur des données typées pour finalement les insérer là où tu veux dans une query string et une intégration au langage comme LINQ il y a un monde et il n'est pas évident de savoir où tu mets le curseur pour définir ce fameux système de sécurisation des requêtes universel qui conviendra à tous les usages.
Mes propos concernaient là encore les manques de LINQ, maintenant tu viens me parler de Tex...
De quelle façon tu comptes te servir concrètement d'un tel système pour gérer la problématique évoquée ?
Je ne suis d'ailleurs pas non plus convaincu, à la base, qu'il soit si pertinent de vouloir mixer deux choses très différentes : un langage de programmation et un langage de requête dans une syntaxe commune qui n'exprime pas clairement ce qui sera envoyé au serveur.