Pull to refresh

Comments 9

очень круто.
еще надо работу с регулярными выражениями так сделать, там тоже старое некрасивое java api
В scala регулярки обычно применяются в pattern matching, так что они вполне идеологически верны:
scala> val CardNumber = """.*card number: (\d+).*""".r
CardNumber: scala.util.matching.Regex = .*card number: (\d+).*

scala> "User { name: Bob; card number: 12345 }" match {
     |   case CardNumber(cn) => cn
     |   case _ => "oops"
     | }
res0: String = 12345


Теоретически можно добавить валидацию во время компиляции, но мне кажется оно того не стоит.
В pattern matching — это Regex.unapply(), к этому никаких претензий нет, это не наследие Java

А вот например Regex.replaceSomeIn(str: CharSequence, replacer: (Match) ⇒ Option[String]) у которого в возвращаемом replacer'ом Option[String] специальным образом интерпретируются символы '$' — это бяка и пережиток проклятого прошлого.

Нельзя вот просто взять и написать
  "%([0-9A-F]{2})".r.replaceAllIn(str, m => Integer.parseInt(m.group(1), 16).toChar.toString)

сейчас приходится писать так:
  "%([0-9A-F]{2})".r.replaceAllIn(str, m => Integer.parseInt(m.group(1), 16).toChar.toString.replace("\\", "\\\\").replace("$", "\\$"))
красиво, правда?

а хочется чего-то вроде
  str =~ rx"%([0-9A-F]{2})" ^^ (x => Integer.parseInt(x, 16).toChar.toString)
число параметров лямбды можно вывести из числа () в regex

Ну и компиляция регекспа на этапе компиляции скала-программы, да, полезно.
И дедубликация одинаковых regex'пов (сейчас маросами можно добавлять методы в некий глобальный object).
Да действительно. Просто ни когда не пользовался.

Кроме автоматического экранирования сложно что-нибудь придумать.

Вот ускорить не получится, не меняя «базу» — судя по беглому осмотру java.util.regex.Pattern можно получить только из строки — а значит в рантайме. Разве что действительно через хранилище глобальное оптимизировать — чтобы дважды не создавать один регекс, но тут надо гарантировать отсутствие проблем с доступом из разных потоков.

В общем я не возьмусь. Будете реализовывать — обращайтесь за советом, если понадобится.
Встраивать же в регулярные выражения переменные или функции из контекста не требуется.
А расскажите про Scala пожалуйста.
Там так же как в Java и C# крайне нелогичная работа с большинством объектов в духе

Object.toString()
или
«dfsd».indexOf()

? Или все таки там понимают, что метод объекта должен изменять объект, а не возвращать другой?

Выбираю язык в очередной раз, пока C++ в топе, но тоже многое не устраивает.
Как раз в Scala есть сильный упор на иммутабельность (val vs var). Которая в свою очередь означает, что объект вообще нельзя изменить. И это замечательно!
Интересно, как Вы обходитесь с const объектами в C++?
Если объект нельзя изменить, то это структура данных. Объект по определению имеет состояние, свойства и методы для их изменения.

const объекты это как раз то, что меня не устраивает в C++. А конкретно — бесконечное число применений, нет единой ответственности за функциональность. А главное нет никакой логики в их существовании, при проектировании они просто не нужны.

Спасибо, что рассказали про иммутабельность в Scala — не буду даже смотреть в его сторону :-)

Аргументы на всякий случай:

Чем больше объект знает о других объектах (toString означает что все объекты должны знать об объекте String), тем выше связность в системе и т.д.
Мы ожидаем от объекта методов, связанных с ним, а не с чем угодно (к примеру с ним и строкой).

И Java и C# и Javascript(хотя в нем получше из за отсутствия фреймворка в коробке) — целые языки и платформы созданные на неверной идеологии. Теперь, видимо, для меня в копилку добавляется Scala :-)
Only those users with full accounts are able to leave comments. Log in, please.