DSL для регулярных выражений на Kotlin

[temas]

Это действительно хорошее применение DSL — ведь сырой regex читается с трудом. Но я в своей работе DSL так никогда и не использовал, — то ли задач не было то ли не смог найти адекватное применение. Было бы интересно так же почитать как DSL помогает в других рутинных, но реальных задачах.

[S_A]

Я постоянно использую собственный достаточно простой класс ComposedRegex для парсинга мэйлов, телефонов, почтовых шаблонов, шаблонов сообщений пользователю. На статью такой кейс не потянет, но задачи реальные, рутинные и повседневные…

[senia]

Отвечая на вопрос в конце:
Если мы отказываемся от компактного синтаксиса регулярных выражений, то лучше уж сразу перейти к комбинаторным парсерам.
Примеры на scala: http://www.artima.com/pins1ed/combinator-parsing.html. Мой опыт с ними: https://habrahabr.ru/post/176285/
Пример с byte на парсерах:

object byteParser extends JavaTokenParsers {
  def digit = elem("digit", '0' to '9' toSet)
  def top = "25" ~ elem("0 to 5", '0' to '5' toSet)
  def middle = '2' ~ elem("0 to 4", '0' to '4' toSet) ~ digit
  def low = ("0" | "1") ~ digit ~ digit | digit ~ digit.?
  def byte = top | middle | low

  def apply(s: String) = parseAll(byte, s)
}


println(byteParser("256"))
//failure: 0 to 5 expected
//
//256
//  ^

[ReinRaus]

Дам всего один простой совет: если не можете прочитать сложное регулярное выражение- в коде в комментарии к нему указывайте ссылку на regex101, там редактируйте его с подсветкой синтаксиса, подсказками, тестами. И не забывайте про режим eXtended- в нем регулярные выражения любой сложности читаются очень легко.
Сложное регулярное выражение на DSL будет гораздо большим трэшем, чем его обычная запись, как мне кажется.

[UbuRus]

У любого кода, синтаксиса, DSL есть особенность — пока ты с ним плотно работаешь — он читается и понятен, как только ты его не видел какое-то время он забывается. Для меня возвращение к сложным регекспам на разных языках (с учетом того что тут 14 стандартов) всегда боль, и тут конечно же regex101 like удобно. Но зачем сервис, если есть такой приятный DSL, с которым я легко прочитал все примеры? При этом с Kotlin, в отличии от других языков, не нужно поддерживать хинты для IDE или еще что-то, IDE подсказывает мне что я могу использовать в конкретном месте без лишних телодвижений со стороны автора или пользователя.

[dougrinch]

да и банальной проверки соответствия открывающих и закрывающих элементов нет, можно написать лишний .end();

Так можно же проверку сделать! Так что и лишний не напишешь, и не лишний не забудешь.

[h0tkey]

Согласен, во время написания поста тоже думал, что для цепочек вызовов это должно быть осуществимо примерно так, как написано у вас (спасибо что показали, как именно!). В таком случае остаётся только такой недостаток, как необходимость воевать с форматтером, чтобы он не выровнял все вызовы функций.

[dougrinch]

Это да, потому и не стал цитировать пункт целиком. Более того, я боюсь что в этой войне его вообще не победить. Максимум, что можно было бы сделать (да и то хз как) — запретить форматировать конкретный кусок. Но, на мой взгляд, вторая проблема (динамический запрос) даже хуже.

А у вас хорошо получилось, статическая типизация — наше всё.

[h0tkey]

Форматтеру IDEA вполне можно запретить форматировать участок кода, но по умолчанию эта фича выключена. Например, здесь это позволило избежать лишнего большого отступа, который бы добавился из-за того, что это аргумент конструктора. :)