Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
очень круто.
еще надо работу с регулярными выражениями так сделать, там тоже старое некрасивое java api
еще надо работу с регулярными выражениями так сделать, там тоже старое некрасивое 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] специальным образом интерпретируются символы '$' — это бяка и пережиток проклятого прошлого.
Нельзя вот просто взять и написать
сейчас приходится писать так:
а хочется чего-то вроде
Ну и компиляция регекспа на этапе компиляции скала-программы, да, полезно.
И дедубликация одинаковых regex'пов (сейчас маросами можно добавлять методы в некий глобальный object).
А вот например 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'пов (сейчас маросами можно добавлять методы в некий глобальный object).
Да действительно. Просто ни когда не пользовался.
Кроме автоматического экранирования сложно что-нибудь придумать.
Вот ускорить не получится, не меняя «базу» — судя по беглому осмотру java.util.regex.Pattern можно получить только из строки — а значит в рантайме. Разве что действительно через хранилище глобальное оптимизировать — чтобы дважды не создавать один регекс, но тут надо гарантировать отсутствие проблем с доступом из разных потоков.
В общем я не возьмусь. Будете реализовывать — обращайтесь за советом, если понадобится.
Кроме автоматического экранирования сложно что-нибудь придумать.
Вот ускорить не получится, не меняя «базу» — судя по беглому осмотру java.util.regex.Pattern можно получить только из строки — а значит в рантайме. Разве что действительно через хранилище глобальное оптимизировать — чтобы дважды не создавать один регекс, но тут надо гарантировать отсутствие проблем с доступом из разных потоков.
В общем я не возьмусь. Будете реализовывать — обращайтесь за советом, если понадобится.
Встраивать же в регулярные выражения переменные или функции из контекста не требуется.
А расскажите про Scala пожалуйста.
Там так же как в Java и C# крайне нелогичная работа с большинством объектов в духе
Object.toString()
или
«dfsd».indexOf()
? Или все таки там понимают, что метод объекта должен изменять объект, а не возвращать другой?
Выбираю язык в очередной раз, пока C++ в топе, но тоже многое не устраивает.
Там так же как в Java и C# крайне нелогичная работа с большинством объектов в духе
Object.toString()
или
«dfsd».indexOf()
? Или все таки там понимают, что метод объекта должен изменять объект, а не возвращать другой?
Выбираю язык в очередной раз, пока C++ в топе, но тоже многое не устраивает.
Как раз в Scala есть сильный упор на иммутабельность (
Интересно, как Вы обходитесь с
val vs var). Которая в свою очередь означает, что объект вообще нельзя изменить. И это замечательно!Интересно, как Вы обходитесь с
const объектами в C++?Если объект нельзя изменить, то это структура данных. Объект по определению имеет состояние, свойства и методы для их изменения.
const объекты это как раз то, что меня не устраивает в C++. А конкретно — бесконечное число применений, нет единой ответственности за функциональность. А главное нет никакой логики в их существовании, при проектировании они просто не нужны.
Спасибо, что рассказали про иммутабельность в Scala — не буду даже смотреть в его сторону :-)
Аргументы на всякий случай:
Чем больше объект знает о других объектах (toString означает что все объекты должны знать об объекте String), тем выше связность в системе и т.д.
Мы ожидаем от объекта методов, связанных с ним, а не с чем угодно (к примеру с ним и строкой).
И Java и C# и Javascript(хотя в нем получше из за отсутствия фреймворка в коробке) — целые языки и платформы созданные на неверной идеологии. Теперь, видимо, для меня в копилку добавляется Scala :-)
const объекты это как раз то, что меня не устраивает в C++. А конкретно — бесконечное число применений, нет единой ответственности за функциональность. А главное нет никакой логики в их существовании, при проектировании они просто не нужны.
Спасибо, что рассказали про иммутабельность в Scala — не буду даже смотреть в его сторону :-)
Аргументы на всякий случай:
Чем больше объект знает о других объектах (toString означает что все объекты должны знать об объекте String), тем выше связность в системе и т.д.
Мы ожидаем от объекта методов, связанных с ним, а не с чем угодно (к примеру с ним и строкой).
И Java и C# и Javascript(хотя в нем получше из за отсутствия фреймворка в коробке) — целые языки и платформы созданные на неверной идеологии. Теперь, видимо, для меня в копилку добавляется Scala :-)
Scala поражает, спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Язык в языке или встраиваем XPath в Scala