Tengo una función, parseQuery, que analiza una consulta SQL en una representación abstracta de esa consulta.
Estoy a punto de escribir una función que toma una representación abstracta de una consulta y devuelve una cadena de consulta SQL.
¿Qué debería llamar la segunda función?
Respuestas:
Creo que el verbo que quieres es 'componer'.
Lo contrario de parse es serializar
En la terminología del compilador, lo contrario es "no analizar". Específicamente, el análisis convierte una secuencia de tokens en árboles de sintaxis abstracta, mientras que la descompresión convierte los árboles de sintaxis abstracta en una secuencia de tokens.
¿Componer? Al analizar una consulta, la divide en sus partes constituyentes (tokens, etc.), lo contrario sería componer las partes en una consulta de cadena.
Para complementar su nomenclatura existente, composeQuery se ve mejor.
Pero en el caso general, lo contrario de parse es ǝsǝd
Creo que "serializar" es probablemente la palabra que quieres. Significa producir una representación textual de datos que se pueden exportar (e importar) desde el programa.
Definitivamente Render.
generar o emitir, posiblemente.
Solo para agregar algunas cosas.
Seguramente analizar es una palabra de dos vías.
Puede analizar un resumen en una consulta.
Puede analizar una consulta en un resumen.
La pregunta debería ser, ¿cómo nombra la última parte del método y porque en este caso está analizando un resumen para hacer una consulta, la llamaría parseAbstract?
Para responder a la pregunta, el análisis no tiene opuesto.
Elige tu opción
Cada uno tiene connotaciones ligeramente diferentes.
Tal vez prettyPrintQuery ?
Un compilador tradicional tiene dos partes: un analizador y un generador de código.
Entonces podrías llamarlo "Generar". Por supuesto, aquí es un poco diferente porque el compilador no está escribiendo el código fuente. (a menos que sea un precompilador).
Posiblemente Formato (). o ToSQL () en tu instancia?
unParse ()? Es broma, iría con toQueryString ()
¿aplanar?
El objeto de consulta analizado tal vez representa una jerarquía de condición, que está "aplanando" de nuevo en una cadena de 1 dimensión.
Pero dado que va de un objeto a una cadena, realmente use toString o toSQL () o algo así. Además, si lo diseñó bien y está utilizando la aplicación correcta, puede cambiarle el nombre más tarde y simplemente pegar cosas en los comentarios sobre lo que hace.
Yo diría serializar y deserializar, en lugar de analizar y ...
Optaría por ToString (), ya que generalmente puedes encadenarlos (funciones opuestas, que te permiten pasar de Class1 a Class2 y viceversa)
DateTime.Parse( DateTime.Parse( myDate.ToString() ).ToString() );
Serialize () parece una buena opción, pero ya tiene un opuesto en Deserialize ().
En su escenario específico, como señaló otro, ToSql () es otra buena opción.
Yo usaría render
> 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>
Que es mi humilde opinión, lo contrario de parse ()
> c = parse(b)
{ 'html': {
'head': {
'title': 'My Page'
}
'body': {
'h1': 'Hello World',
'p': 'This is a Paragraph'
}
}
Usualmente uso "parse" como método de conversión y, por lo tanto, no puedo encontrar una palabra opuesta para "convertir". (no puede "desconvertir" algo, ya que "desconvertir" es un tipo de conversión en sí mismo).
pensando de esta manera, la mejor solución (para mí) es tener dos métodos de "análisis" que reciban diferentes argumentos. Ejemplo (Java):
public class FooBarParser{
public Foo parse(Bar bar);
public Bar parse(Foo foo);
}
desaparecer
Deparse es analizar, como:
El análisis / análisis no es un cambio de estructura, sino una conversión. Conversión precisa entre texto equivalente y formatos de árbol de sintaxis abstracta, manteniendo todas las relaciones y estructura.
"Componer" significa cambio de estructura, por lo que no es del todo correcto. Sugiere combinar desde partes independientes separadas (generalmente por primera vez). Así como "descomponer" sugiere dividir en partes independientes. Cambian de forma, no solo de formato.
Una búsqueda rápida muestra el término utilizado en: