I have a function, parseQuery, that parses a SQL query into an abstract representation of that query.
I'm about to write a function that takes an abstract representation of a query and returns a SQL query string.
What should I call the second function?
I think the verb you want is 'compose'.
In compiler terminology, the opposite is "unparse". Specifically, parsing turns a stream of tokens into abstract syntax trees, while unparsing turns abstract syntax trees into a stream of tokens.
Compose? When parsing a query you break it into its constituent parts (tokens, etc.), the reverse would be composing the parts into a string query.
To complement your existing naming, composeQuery looks best.
But in the general case, the opposite of parse is ǝsɹɐd
I think "serialize" is probably the word you want. It means to produce a textual representation of data that can be exported (and imported) from the program.
I would call it constructQuery.
generate or emit, possibly.
Just to add some stuff.
Surely parse is a two way word.
You can parse an abstract into a query.
You can parse a query into an abstract.
The question should be, what do you name the latter part of the method, and because in this instance you're parsing an abstract to make a query you'd call it parseAbstract.
To answer the question, parsing has no opposite.
Take your pick
They each have slightly different connotations.
compose, construct, generate, render,condense, reduce, toSQL, toString depending on the nature of the class and its related operators
A traditional compiler has two parts: a parser and a code generator.
So you could call it "Generate". Of course, it's a little bit different here because the compiler isn't writing source code. (unless it's a precompiler).
flatten?
The parsed query object perhaps represents a condition hierarchy, which you are "flattening" back into a 1 dimensional string.
But given that you're going from object to string, really just use toString or toSQL() or something like that. Besides, if you designed it well and are using the right app, you can rename it later and just stick stuff in the comments on what it does.
I would go for ToString(), since you can usually chain-nest them (opposite functions, that let you pass from Class1 to Class2 and vice-versa)
DateTime.Parse( DateTime.Parse( myDate.ToString() ).ToString() );
Serialize() looks like a nice choice, but it already has an opposite in Deserialize().
In your specific scenario, as other pointed out, ToSql() is another good choice.
I'd use 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>
Which is IMHO, the opposite to parse()
> c = parse(b)
{ 'html': {
'head': {
'title': 'My Page'
}
'body': {
'h1': 'Hello World',
'p': 'This is a Paragraph'
}
}
INHO Serialize, synthesize are good options. Also, as you have named parseQuery, i will go with codeQuery
I voted for 'compose' but if you don't like that I would also suggest 'build'
I usually use "parse" as a conversion method and, therefore, i can't find a opposite word for "convert". (you can't "deconvert" something, as "unconvert" is a type of conversion itself).
thinking this way, the best solution (for me) is having two "parse" methods that receive different arguments. Example (Java):
public class FooBarParser{
public Foo parse(Bar bar);
public Bar parse(Foo foo);
}
deparse
Deparse is to parse, as:
Parsing / deparsing is not change of structure, but conversion. Precise conversion between equivalent text and abstract-syntax-tree formats, maintaining all relationships & structure.
"Compose" means change of structure, so is not quite right. It suggests combining from separate independent parts (usually for the first time). Just as "decompose" suggests splitting into independent parts. They change form, not just format.
A quick search show's the term's used within:
writeQuery. Parse is the act of reading it from a string and creating the object (let's say 'actual') representation. The opposite would be writing the object into a string.
I believe the answer you're looking for is: "Don't parse SQL or assemble SQL in the first place. Use an Object/Relational Mapper and stop wasting your employer's money by solving problems that have already been solved for quite some time."
