Quel est le contraire de «parse»?
J'ai une fonction, parseQuery, qui analyse une requête SQL en une représentation abstraite de cette requête.
Je suis sur le point d'écrire une fonction qui prend une représentation abstraite d'une requête et renvoie une chaîne de requête SQL.
Comment dois-je appeler la deuxième fonction?
Je pense que le verbe que vous voulez est "composer".
L'opposé de analyser est sérialiser
Dans la terminologie du compilateur, l'opposé est "non analysé". Plus précisément, l'analyse transforme un flux de jetons en arbres de syntaxe abstraite, tandis que l'analyse ne transforme pas les arbres de syntaxe abstraite en un flux de jetons.
Composer? Lorsque vous analysez une requête, vous la divisez en ses parties constituantes (jetons, etc.), l'inverse serait de composer les parties en une requête de chaîne.
Pour compléter votre dénomination existante, composeQuery est la meilleure.
Mais dans le cas général, l'opposé de parse est ǝsɹɐd
J'utiliserais l'un d'eux:
- ToString ()
- ToSQL ()
- Rendre()
Je pense que "sérialiser" est probablement le mot que vous voulez. Cela signifie produire une représentation textuelle des données qui peuvent être exportées (et importées) à partir du programme.
L'antonyme de "analyser" est "synthétiser".
ToQueryString ()
Certainement rendu.
Juste pour ajouter quelques trucs.
Analyser est certainement un mot à double sens.
Vous pouvez analyser un résumé dans une requête.
Vous pouvez analyser une requête dans un résumé.
La question devrait être, comment nommez-vous la dernière partie de la méthode, et parce que dans ce cas, vous analysez un résumé pour faire une requête, vous l'appeleriez parseAbstract.
Pour répondre à la question, l'analyse n'a pas d'opposé.
Je l'appellerais constructQuery.
générer ou émettre, éventuellement.
generateQuery, peut-être? createQuery?
Faites votre choix
- Produire
- Déverser
- Sérialiser
- Émettre
Ils ont chacun des connotations légèrement différentes.
Peut-être prettyPrintQuery ?
composer, construire, générer, restituer, condenser, réduire, toSQL, toString selon la nature de la classe et ses opérateurs associés
Un compilateur traditionnel se compose de deux parties: un analyseur et un générateur de code.
Vous pouvez donc l'appeler "Générer". Bien sûr, c'est un peu différent ici car le compilateur n'écrit pas de code source. (sauf s'il s'agit d'un précompilateur).
Formater éventuellement (). ou ToSQL () dans votre instance?
unParse ()? Je plaisante, j'irais avec toQueryString ()
Je dirais sérialiser et désérialiser, au lieu d'analyser et ...
aplatir?
L'objet de requête analysé représente peut-être une hiérarchie de conditions, que vous "aplatissez" en une chaîne à 1 dimension.
Mais étant donné que vous passez de l'objet à la chaîne, utilisez simplement toString ou toSQL () ou quelque chose comme ça. De plus, si vous l'avez bien conçue et utilisez la bonne application, vous pouvez la renommer plus tard et simplement coller des éléments dans les commentaires sur ce qu'elle fait.
J'utiliserais le rendu
> a = 'html': { 'head': {'title': 'My Page'}, 'body': { 'h1': 'Hello World', 'p': 'This is a Paragraph' } }
> b = render(a)
> console.log(b)
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Hello World</h1>
<p>This is a Paragraph</p>
</body>
</html>
Qui est à mon humble avis, l'opposé de parse ()
> c = parse(b)
{ 'html': {
'head': {
'title': 'My Page'
}
'body': {
'h1': 'Hello World',
'p': 'This is a Paragraph'
}
}
Je choisirais ToString (), car vous pouvez généralement les imbriquer en chaîne (fonctions opposées, qui vous permettent de passer de Class1 à Class2 et vice-versa)
DateTime.Parse( DateTime.Parse( myDate.ToString() ).ToString() );
Serialize () ressemble à un bon choix, mais il a déjà un opposé dans Deserialize ().
Dans votre scénario spécifique, comme d'autres l'ont souligné, ToSql () est un autre bon choix.
J'utilise habituellement "parse" comme méthode de conversion et, par conséquent, je ne trouve pas de mot opposé pour "convertir". (vous ne pouvez pas "déconvertir" quelque chose, car "déconvertir" est un type de conversion lui-même).
de cette façon, la meilleure solution (pour moi) est d'avoir deux méthodes "d'analyse" qui reçoivent des arguments différents. Exemple (Java):
public class FooBarParser{
public Foo parse(Bar bar);
public Bar parse(Foo foo);
}
Et asSQL () ou encore asQuery ()?
INHO Sérialiser, synthétiser sont de bonnes options. Aussi, comme vous l'avez nommé parseQuery, j'irai avec codeQuery
+1 pour Générer, mais insister sur ce que vous générez, c'est-à-dire GenerateSQL ()
J'ai voté pour "composer", mais si vous n'aimez pas cela, je suggère également de "construire"
analyse
Déparse consiste à analyser, comme:
- décompiler est de compiler
- décomposer c'est composer
- désérialiser consiste à sérialiser
- degroovy est trop groovy :);)
L'analyse/l'analyse n'est pas un changement de structure, mais une conversion. Conversion précise entre le texte équivalent et les formats d'arbre à syntaxe abstraite, en conservant toutes les relations et la structure.
"Composer" signifie un changement de structure, ce n'est donc pas tout à fait raison. Il suggère de combiner des parties indépendantes distinctes (généralement pour la première fois). Tout comme "décomposer" suggère de se scinder en parties indépendantes. Ils changent de forme, pas seulement de format.
Une recherche rapide est le terme utilisé dans:
- Perl: http://perldoc.Perl.org/B/Deparse.html
- R: http://www.hep.by/gnu/r-patched/r-lang/R-lang_98.html
- LISP commun: http://www.clisp.org/impnotes/dffi.html#c-type-parse
- PostgreSQL: http://doxygen.postgresql.org/deparse_8c.html
- Eclipse: http://www.Eclipse.org/forums/index.php/t/201883/
- Unix Korn Shell: http://www.sourcecodebrowser.com/ksh/93tplus-p/deparse_8c.html
writeQuery. L'analyse est l'acte de le lire à partir d'une chaîne et de créer la représentation d'objet (disons "réelle"). L'inverse serait d'écrire l'objet dans une chaîne.
.GetSqlQuery() serait mon choix