Меня лично, всегда изумлял http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/net/URL.java авторства самого Гослинга

Да, я вот до сих пор слезу пускаю при упонимании того, что в котлине хотят сделать SAM-интерфейсы.

А что плохого с SAM-ами. Я по дурости видимо за них голосовал...

А что там не так?

extends Hashtable как минимум, это НЕ МОГЛО пройти кодревью, и, наверное, было кем-то засунуто прямо в мастер

Они вроде в языке ничего не портят...

extends Hashtable как минимум, это НЕ МОГЛО пройти кодревью, и, наверное, было кем-то засунуто прямо в мастер

Так это когда было

HashTable тогда был жив. А потом умер

Так это когда было

а тогда понятие говнокода было иным?

А что там не так?

То, как оно работает с дженериками, как минимум

Тогда j.u.collections и не было природе еще

вы про префы или про проперти

То, как оно работает с дженериками, как минимум

когда его писали, не было дженериков)

Оно все создавалось как альтернатива ini. И поверьте мне (я еще на паскале писал, когда он жив был), очень хорошая инициатива. Сейчас, конечно, давно протухло.

Оно все создавалось как альтернатива ini. И поверьте мне (я еще на паскале писал, когда он жив был), очень хорошая инициатива. Сейчас, конечно, давно протухло.

сам формат .properties ок, мы говорим про java.util.Properties

когда его писали, не было дженериков)

Ну с остальными классами коллекций их же нормально интегрировали Но корни проблем конечно в extends Hashtable

Так и он был хорош... по тем временам.

Ну с остальными классами коллекций их же нормально интегрировали Но корни проблем конечно в extends Hashtable

кого с кем интегрировали?

Так и он был хорош... по тем временам.

нет, он экстендит коллекцию. Нефинальные коллекции — тоже косяк

кого с кем интегрировали?

Дженерики с Java Collections Framework

Дженерики с Java Collections Framework

добавление дженериков в класс не ломает существующий код

а вот extends GenericClass<Concrete arguments> ломает

Мы сейчас это понимаем. По тем временам - это считалось годным решением. Объектный угар, наследование и полиморфизм. Я думаю, что класс вообще создавался как финальный для конкретного внутреннего использования. Я и в более позднем коде такие решения видел.

добавление дженериков в класс не ломает существующий код

Да, но в новом коде приходится работать с Map<Object, Object>, хотя на деле ключи это строки

Да, но в новом коде приходится работать с Map<Object, Object>, хотя на деле ключи это строки

вообще не надо использовать Properties как Map.

Ими вообще лучше не пользоваться. Не понятно, зачем.

Парсить .properties файлы вручную

...а, у меня удалили стикер

ну да

Ими вообще лучше не пользоваться. Не понятно, зачем.

очень неплохая альтернатива ini, но лучше не пользоваться?

...а, у меня удалили стикер

они удаляются автоматом

Ага, я забыл

А кто сейчас ini пользуется? Это было в доXMLную эру

А кто сейчас ini пользуется? Это было в доXMLную эру

XML типа альтернатива ini?)

Ну для хранения конфигурации да.

Ну для хранения конфигурации да.

<PostgreSQL> <login>user</login> <password>qwerty123</password> </PostgreSQL> хмм, заманчиво

Не вижу, в чем проблема.

ну если нужна хоть какая-то иерархия, YAML гораздо привлекательнее

Эра json еще не наступила?:)

etcd!

вроде все варианты рассмотрели, нет?

Да любой иерархический формат. XML просто встроен в JVM, остальное нет.

Правда к вопросу о граблях, мне очень не нравится стандартная реалзиация XML

Да любой иерархический формат. XML просто встроен в JVM, остальное нет.

В JDK? встроенные парсеры использовать не особо приятно

Да, там API кошмарненький :)

Минимальная Json библиотека всего несколько десятков килобайт. Если и так таскаешь с собой kotlin-stdlib, то в общем-то не жалко.

как жаль, что JSON — такое говно

* в контексте статических языков

Да любой иерархический формат. XML просто встроен в JVM, остальное нет.

Кстати, походу JSON API в десятке так и не зарелизили. Очень видно, как востребовано.

Javax.json примерно такой же кошмарный, как и стандартный XML. Думаю, что поэтому и не запихали.

как жаль, что JSON — такое говно

Все что угодно, что превращается в строку. Можете взять BSON, но забудьте тогда про человекочитаемость.

Все что угодно, что превращается в строку. Можете взять BSON, но забудьте тогда про человекочитаемость.

Отвратная концепция token = Number | String | Map<String, token> | List<token>, к сожалению, остаётся.

А что в ней плохого?

А что в ней плохого?

ужасный лапшекод при попытке использовать из статического языка

Не вижу проблемы, честно говоря. Пишется один раз when на входе и усе. Я правда не исползую Json внутри кода, только при чтении конфигурации.

ужасный лапшекод при попытке использовать из статического языка

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

Пишем файл в пару строк, читаем тоже, и у нас готовые объекты, коллекции в памяти

Не вижу проблемы, честно говоря. Пишется один раз when на входе и усе. Я правда не исползую Json внутри кода, только при чтении конфигурации.

when (token) { is Number -> is String -> is List<*> -> is Map<*, *> -> } разве это не ужасно?

Нет.

Зависит от того, что именно надо

Если на входе сразу превращать в свою структуру, то эта штука вообще один раз встречается. Как верно было замечено, можно вообще взять что-то типа jackson и просто напрямую превращать файлы в объекты (я так не делаю, но это можно).

Обычно кстати такой фигни нет, поскольку при чтении заранее знаешь, что именно ожидаешь увидеть в поле с определенным именем. Надо только поставить проверку на ошибку.

Можно хлебнуть говна. Можно совсем немножко, а можно посредством библиотеки.

Просто в котлине все еще нет паттерн матчинга

*картинка с ослом из шрека*

Вот уж священная корова этот ваш паттерн матчинг.

Я понимаю, зачем бывают нужны тайп-классы, но полноценный паттерн матчинг - это по-моему просто фетиш.

Просто в котлине все еще нет паттерн матчинга

надеюсю, что и не будет

А что делать, он слишком удобный

А что делать, он слишком удобный

для чего?

Поддерживаю предыдущего оратора

Как раз чтобы структуры разбирать

Но да, в Котлине не приживется

Как раз чтобы структуры разбирать

нетипизированные? с ними лучше не работать вовсе

А как же компиляторы писать без этого ;)

Где-то была дискуссия с людьми от JetBrains, они сказали, что будут думать про паттерн матчинг, если кто-нибудь реально приведет пример, где без него никак. Никто не привел.

А как же компиляторы писать без этого ;)

вот, я только вспомнил, что Браслав говорил!

Вот компилятор - это был как раз в этой дискусси единственный use-case/

Парсить .properties файлы вручную

Lightbend Config - наше всё

Хороший пример адекватного паттерн-матчинга это, например, в динамическом функциональном языке жисон разбирать (привет эликсир)

Не надо пожалуйста динамических функциональных языков.

Никто не сомневается, что чисто функциональные языки без этого не живут, что статические, что динамические, ну а нам-то, рыбам, зачем.

Хороший пример адекватного паттерн-матчинга это, например, в динамическом функциональном языке жисон разбирать (привет эликсир)

Вброшу. А чем smart cast не адекватен?

до ума не доведен (пока?)

Я уже не вспомню, в чем проблема была, когда делаешь проверку на null, а оно не кастится к не-нулабл типу

Вспомнить бы кейс

до ума не доведен (пока?)

Ну это уже на уровне городских легенд.

Да нет, траблы иногда вполне осязаемые

Вспомнить бы кейс

Я бы предложил отсутствие глубокого деструктурирования, но вот это совсем ни разу не понадобилось пока

Просто в котлине все еще нет паттерн матчинга

(а в чем проблемма взять скалу?)

Слишком мейнстримно, камон

И убиться об нее :)

Я уже не вспомню, в чем проблема была, когда делаешь проверку на null, а оно не кастится к не-нулабл типу

если проверка внутри функции. но это контракты вылечат

сорри за офтоп. Отстал.Не нашел Почему в Идее в Джаве переменные предваряются "val" вместо их типа (с какого-то врем. помимо SAM замены на лямбды, и до кликатна коде)? Разве в джаве тоже val уже вводится ?

java10

а убрать это (только это, не лямбды) можно?

Я уже не вспомню, в чем проблема была, когда делаешь проверку на null, а оно не кастится к не-нулабл типу

В случае если переменная мутабельна?

в Джаве(не котлине) все кр.final мутабельны. неудобно. путаешь сырцы с котлином токо.