Что противоположно синтаксическому анализу?
У меня есть функция parseQuery, которая анализирует запрос SQL в абстрактное представление этого запроса.
Я собираюсь написать функцию, которая принимает абстрактное представление запроса и возвращает строку запроса SQL.
Как мне назвать вторую функцию?
Ответы 33
generateQuery, возможно? createQuery?
Возможно форматирование (). или ToSQL () в вашем экземпляре?
Я бы назвал это constructQuery.
Звучит почти идеально. Вот что могло бы произойти. Он будет собирать данные, которые можно «выразить словами». Он будет «строить» запрос.
ToQueryString ()
Я думаю, вам нужен глагол «сочинять».
@ Джоэл: twitter.com/shanselman/status/5024768993
Я имею в виду, что, вернувшись через год, я бы даже ответил «собрать» как лучшую противоположность или «построить» как лучшее имя функции.
Ого, я не проверял даты на этом ... ТАК вопрос, некромантия!
эээ .. почему не ToString ()? Кажется, это стандарт, установленный такими, как Int32 и т. д.
сделал свой предыдущий комментарий, прежде чем увидел, что вопрос не зависит от языка. ToString () кажется принятым стандартом .NET
Сейчас стоит 140 (17.12.2014); Я думаю, что это полезный ответ, поэтому я проголосовал за него, но, конечно, это не эквивалент сложной программы; конечно, подобное слово более "нестареющее", чем определенные технологии программирования.
Может prettyPrintQuery?
генерировать или испускать, возможно.
Я согласен. rfc7159 (JSON), в разделах 9 и 10 определяют «Парсер» и «Генератор» как противоположности.
Антоним слова «анализировать» - «синтезировать».
синтезировать. хороший выбор.
unParse ()? Шучу, я бы пошел с toQueryString ()
Сочинить? При синтаксическом анализе запроса вы разбиваете его на составные части (токены и т. д.), Наоборот, составление частей в строковый запрос.
Я думаю, что "сериализовать" - это, вероятно, то слово, которое вам нужно. Это означает создание текстового представления данных, которые можно экспортировать (и импортировать) из программы.
Сериализация может также легко означать двоичное представление.
Правда. Parsimg - это постепенное исчезновение внешних данных, а сериализация - это создание данных для внешнего использования. Создаваемый формат не обязательно должен быть текстом, но часто бывает.
Судя по всему, клавиатура моего iPod становится лучше меня. Это должно быть «разбор» и «чтение».
Я бы использовал один из них:
- Нанизывать()
- ToSQL ()
- Оказывать()
сплющить?
Разобранный объект запроса, возможно, представляет собой иерархию условий, которую вы «сглаживаете» обратно в одномерную строку.
Но учитывая, что вы переходите от объекта к строке, на самом деле просто используйте toString или toSQL () или что-то в этом роде. Кроме того, если вы хорошо его спроектировали и используете правильное приложение, вы можете переименовать его позже и просто добавить в комментарии то, что оно делает.
Просто чтобы добавить кое-что.
Конечно, синтаксический анализ - это двустороннее слово.
Вы можете разобрать аннотацию в запрос.
Вы можете преобразовать запрос в аннотацию.
Вопрос должен заключаться в том, как вы назовете последнюю часть метода, и поскольку в этом случае вы анализируете аннотация, чтобы сделать запрос, вы бы назвали его parseAbstract.
Чтобы ответить на вопрос, синтаксический анализ не имеет противоположностей.
компоновка, построение, генерация, рендеринг, уплотнение, сокращение, toSQL, toString в зависимости от природы класса и связанных с ним операторов
Традиционный компилятор состоит из двух частей: парсера и генератора кода.
Так что вы могли бы назвать это «Генерация». Конечно, здесь все немного иначе, потому что компилятор не пишет исходный код. (если это не прекомпилятор).
+1 для Generate, но закрепите то, что вы генерируете, например, GenerateSQL ()
writeQuery. Синтаксический анализ - это процесс чтения из строки и создания объекта (скажем, «фактического») представления. Противоположным будет запись объекта в строку.
Я проголосовал за "сочинить", но если вам это не нравится, я бы также предложил "построить".
Я бы сказал сериализовать и десериализовать вместо синтаксического анализа и ...
Противоположностью разбирать является сериализовать.
С моей точки зрения, это может быть самый полезный ответ.
А как насчет «десериализации»?
Определенно рендер.
В терминологии компилятора противоположное слово - «неразборчивый». В частности, синтаксический анализ превращает поток токенов в абстрактные синтаксические деревья, в то время как разбор превращает абстрактные синтаксические деревья в поток токенов.
Как разбить машину ...
Я бы выбрал ToString (), поскольку вы обычно можете размещать их по цепочке (противоположные функции, которые позволяют переходить от Class1 к Class2 и наоборот)
DateTime.Parse( DateTime.Parse( myDate.ToString() ).ToString() );
Serialize () выглядит неплохим выбором, но у него уже есть противоположность в Deserialize ().
В вашем конкретном сценарии, как указывали другие, ToSql () - еще один хороший выбор.
Я считаю, что ответ, который вы ищете: «Не разбирайте SQL и не собирайте SQL в первую очередь. Используйте Object / Relational Mapper и перестаньте тратить деньги вашего работодателя на решение проблем, которые уже были решены в течение некоторого времени. "
-1. Вы понятия не имеете, что он делает. У него могла быть вполне веская причина для этого. Не все приложения одинаковы.
Я должен согласиться, у меня недавно была совершенно хорошая причина для синтаксического анализа SQL, который не имел ничего общего с ORM (который я также использовал в своем проекте).
Я бы хотел услышать эту «совершенно вескую причину». Нет, вообще-то я бы не стал. Я мог бы представить, если бы вы создавали SQL IDE или что-то в этом роде, но даже тогда - зачем вы создаете SQL IDE, когда они уже являются серьезными игроками на рынке?
Причина в том, что нам пришлось превратить запрос «SELECT CustomerId FROM Customer» во что-то вроде «SELECT << field: 25 >> FROM << table: 76 >>». Это легко для простого выбора, очень сложно для сложных запросов.
Скажите, пожалуйста, как nHibernate поможет мне в этом?
Пожалуйста, скажите мне, зачем вы вообще это делаете.
.GetSqlQuery() был бы моим выбором
А как насчет asSQL () или даже больше asQuery ()?
composeQuery выглядит лучше всего в дополнение к существующему именованию.
Но в общем случае противоположностью синтаксического анализа является ǝsɹɐd.
Я думаю, что это наоборот, наоборот, esrap
@agusgambina: вообще-то, в этом есть смысл ... Подумайте о Bourne shell: если ... фантастический случай ... esac
Я бы использовал рендер
> a = 'html': { 'head': {'title': 'My Page'}, 'body': { 'h1': 'Hello World', 'p': 'This is a Paragraph' } }
> b = render(a)
> console.info(b)
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Hello World</h1>
<p>This is a Paragraph</p>
</body>
</html>
Это ИМХО, противоположно parse ()
> c = parse(b)
{ 'html': {
'head': {
'title': 'My Page'
}
'body': {
'h1': 'Hello World',
'p': 'This is a Paragraph'
}
}
Сделайте ваш выбор
- Генерировать
- Свалка
- Сериализовать
- Испускают
У каждого из них немного разные коннотации.
INHO Serialize, synthesize - хорошие варианты. Кроме того, как вы назвали parseQuery, я буду использовать codeQuery
уходить
Депарс должен разбирать, как:
- декомпилировать - это компилировать
- разложить - составить
- десериализация - это сериализация
- degroovy - это круто :);)
Парсинг / депарсинг - это не изменение структуры, а преобразование. Точное преобразование между эквивалентным текстом и форматами абстрактного синтаксического дерева с сохранением всех взаимосвязей и структуры.
«Составить» означает изменение структуры, поэтому это не совсем так. Предлагает объединение из отдельных независимых частей (обычно впервые). Так же, как «разложить» предполагает разделение на независимые части. Они меняют форму, а не только формат.
Быстрый поиск показывает, что термин используется в:
- Perl: http://perldoc.perl.org/B/Deparse.html
- R: http://www.hep.by/gnu/r-patched/r-lang/R-lang_98.html
- Общий Лисп: http://www.clisp.org/impnotes/dffi.html#c-type-parse
- PostgreSQL: http://doxygen.postgresql.org/deparse_8c.html
- Затмение: http://www.eclipse.org/forums/index.php/t/201883/
- Оболочка Unix Korn: http://www.sourcecodebrowser.com/ksh/93tplus-p/deparse_8c.html
Быстрый поиск по коду Github показывает, что термин «deparse» не имеет широкого использования, см. github.com/search?q=deparse - я думаю, что «deparse» - это термин из экосистемы R. - Для меня генерируется противоположность парсингу. В разбор у нас есть предложение и грамматика в качестве входных данных, и мы хотим знать, какова синтаксическая структура и / или семантическое представление предложения. В поколение у нас есть семантическое представление и грамматика в качестве входных данных, и мы хотим найти предложения, соответствующие семантическому представлению.
Я обычно использую «синтаксический анализ» как метод преобразования, и поэтому я не могу найти противоположное слово для «преобразовать». (вы не можете что-то «деконвертировать», так как «неконвертировать» - это сам по себе тип преобразования).
Я думаю, что лучшее решение (для меня) - использовать два метода «синтаксического анализа», которые получают разные аргументы. Пример (Java):
public class FooBarParser{
public Foo parse(Bar bar);
public Bar parse(Foo foo);
}
Stringify? Класс JSON использует эту терминологию. JSON.parse а для противоположного JSON.stringify?