Comments 12
Спасибо за перевод!
Интересно почему он решил примеры типов делать на основе сишных структур. Как минимум такие типы невыразимы в Си в нормальном виде, не говоря уже про некорректность сумм-типов представленных как union.
Сопоставление с образцом... Не сразу понял по заголовку о чём речь в статье будет)
Я, к слову, использую Arch
Ну, наверное, нельзя переводить «i use arch, btw», прикол как-то теряется :)
Сопоставление с образцом
В качестве перевода «pattern matching» пойдёт, возьму на заметку. Но тоже, люди как-то привыкли видеть этот термин именно по-английски, так что я бы в скобках оставлял оригинал.
Спасибо за перевод!
Ну ладно, фича, конечно, полезная и приятная. Но вот скажите, во многих ли программах сопоставление с образцом играет значительную роль, такую, что без неё прямо никак нельзя? Ну на личном примере этого Рагува - да, а у остальных?
Тем более, чтобы Kotlin из-за этого бросать. Там и так when достаточно удобный в сочетании со smart casting, пусть хоть и до вышеописанной конструкции в чём-то не дотягивает. В планах pattern matching и там есть.
Всё понял, кроме того, причём здесь функциональное программирование.
Стрелочки как у лямбд есть? Есть. Значит функциональное программирование, похоже автор так считает.
Просто matching идет из функциональных языков, см Haskel or Scala.
И там он действительный рулит, так как существующая кодовая база изначально разработана соответствующим образом (принцип единого определения поля и параметра, как в java records). Зачем это ООП-ной джаве? Может перепишем все классы на records и sealed/algebric types, чисто по приколу от нечего делать :-) ?
Всё хотел узнать. В Java есть Expression типа таких как в шарпе? Чтобы их можно было интерпретировать
Спасибо за перевод,
Немного философии, очень интересно когда она доберётся до продуктивный систем. Очень много фич для разработчиков библиотек, а они вынуждены поддержку java 8 держать.
А начальники не просто так запрещают использовать свежие версии, виною тому баги в библиотеках, обратная совместимость и особенности версий всего, которые потом влияют на поведение продуктивной системы, а перевод на новое это деньги. А с фига ли вам бизнес должен дать денег на поиграться с новой версией...
Почему большинство использует какую-то 8 или 11 версию, а правильнее сказать какую-то одну. Ведь все мы привыкаем к синтаксису и паттернам написания кода, а менять их дело тяжёлое. Помнить, что тут такой паттерн, тут такой, мало кто будет, надо использовать какой-то один везде в компании(группе...). Язык и привычки дело тонкое и очень закостенелые.
По итогу, не особо верю в то, что он скоро окажется на продуктивных системах массово. А плюсы несомненно отличные.
В Java 21 собираются реализовать сопоставление с образцом – так, глядишь, я снова на этот язык перейду