¿Qué es lo contrario de 'parse'? [cerrado]

147

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?

Simon
fuente
Stringify? La clase JSON usa esta terminología. JSON.parse y para el opuesto JSON.stringify ?
marchita

Respuestas:

200

Creo que el verbo que quieres es 'componer'.

Joel Coehoorn
fuente
3
@Joel: twitter.com/shanselman/status/5024768993
Daniel Schaffer
16
Quiero decir, volviendo un año después, incluso respondería 'ensamblar' como un mejor opuesto, o 'construir' como un mejor nombre de función.
Joel Coehoorn el
3
Oh wow, no verifiqué las fechas de esto ... ¡Así que cuestiona la nigromancia!
Daniel Schaffer
err .. ¿por qué no ToString ()? Parece ser el estándar establecido por personas como Int32, etc.
Joseph Kingry
1
Hice mi comentario anterior antes de ver que la pregunta era independiente del idioma. ToString () parece ser el estándar aceptado por .NET
Joseph Kingry
79

Lo contrario de parse es serializar

Yuval Adam
fuente
1
Esta puede ser la respuesta más útil desde mi perspectiva.
JosephDoggie
8
¿Qué pasa con 'deserializar'?
Den
32

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.

Barry Kelly
fuente
44
Me gusta deshacer un auto ...
Walter Tross
31

¿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.

Michael Brown
fuente
21

Para complementar su nomenclatura existente, composeQuery se ve mejor.

Pero en el caso general, lo contrario de parse es ǝsǝd

danja
fuente
8
Creo que es el inverso, lo contrario sería esrap
agusgambina
@agusgambina: en realidad, esto tiene sentido ... Piensa en Bourne shell: si ... si fuera el caso ... esac
shrike
20

Yo usaría uno de estos:

  • Encadenar()
  • ToSQL ()
  • Hacer()
Sklivvz
fuente
17

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.

Kyle Cronin
fuente
1
Serializar puede significar fácilmente una representación binaria.
Ben Hoffstein
1
Cierto. Parsimg se trata de desvanecerse en datos externos, y la serialización se trata de producir datos para usos externos. No se requiere que el formato producido sea texto, pero a menudo lo es.
Kyle Cronin
Aparentemente, el teclado de mi iPod me está superando. Se supone que eso es "analizar" y "leer".
Kyle Cronin
15

El antónimo de 'analizar' es 'sintetizar'.

Mike F
fuente
44
sintetizar buena elección.
MikeJ
13

ToQueryString ()

pedestal
fuente
12

Definitivamente Render.

David Mitchell
fuente
10

Yo lo llamaría constructQuery.

Segundo
fuente
Eso suena casi perfecto. Eso es lo que estaría pasando. Recopilaría datos que podrían "expresarse en palabras". Él "construiría" una consulta.
Tgwizman
10

generar o emitir, posiblemente.

DGentry
fuente
1
Estoy de acuerdo. rfc7159 (JSON), en las secciones 9 y 10 define "Analizador" y "Generador" como opuestos.
mydoghasworms
10

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.

Henry B
fuente
9

generateQuery, posiblemente? createQuery?

Dre
fuente
8

Elige tu opción

  • Generar
  • Tugurio
  • Publicar por fascículos
  • Emitir

Cada uno tiene connotaciones ligeramente diferentes.

Mike Graham
fuente
7

componer, construir, generar, renderizar, condensar, reducir, toSQL, toString dependiendo de la naturaleza de la clase y sus operadores relacionados

MikeJ
fuente
6

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).

Walter Mitty
fuente
5

Posiblemente Formato (). o ToSQL () en tu instancia?

Omar Kooheji
fuente
5

unParse ()? Es broma, iría con toQueryString ()

Ben Hoffstein
fuente
4

¿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.

Josh
fuente
4

Yo diría serializar y deserializar, en lugar de analizar y ...

Christophe Herreman
fuente
4

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.

Filini
fuente
4

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'
    }
}
Herman Junge
fuente
3

+1 para Generar, pero agregue lo que está generando, es decir, GenerateSQL ()

Tom Lahti
fuente
3

He votado a favor de "componer" pero si no te gusta, también te sugiero "compilar"

Chico
fuente
3

¿Qué pasa con asSQL () o incluso más con asQuery ()?

Müge
fuente
3

INHO Serializar, sintetizar son buenas opciones. Además, como ha llamado parseQuery, iré con codeQuery

mbmihura
fuente
3

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); 
}
David Paulo
fuente
2

desaparecer

Deparse es analizar, como:

  • descompilar es compilar
  • descomponer es componer
  • deserializar es serializar
  • degroovy es maravilloso :);)

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:

Glen Best
fuente
Una búsqueda rápida del Código Github revela que el término "desaparecer" no tiene un uso generalizado, consulte github.com/search?q=deparse - Pienso en "desaparecer" como un término del ecosistema R. - Para mí, lo opuesto al análisis es generar. En el análisis , tenemos una oración y una gramática como entrada y queremos saber cuál es la estructura sintáctica y / o la representación semántica de la oración. En generación , tenemos una representación semántica y una gramática como entrada y queremos encontrar oraciones que correspondan a la representación semántica.
Jens A. Koch