Size: a a a

2020 October 27

T

Tagir in pro.jvm
Sam Panza
Пфф, Чирухин. Так себе авторитет
Он просто любит шаловливыми ручками внутренности пощекотать. Хакерская натура. Но у серьёзных людей так не принято
источник

VP

Vladimir Petrakovich in pro.jvm
Tagir
Вот сейчас sealed interfaces завезут, и авторы библиотечного кода вообще нормально заживут
Неделя Java 16: количество интерфейсов с одной прибитой гвоздями реализацией выросло втрое!
источник

I

Igor in pro.jvm
Tagir
Он просто любит шаловливыми ручками внутренности пощекотать. Хакерская натура. Но у серьёзных людей так не принято
серьезные люди форкают
источник

VP

Vladimir Petrakovich in pro.jvm
Есть такая практика у некоторых: создавать интерфейс и писать в доке, что реализовывать его самому нельзя, ибо могут появиться новые методы и всё сломается. Теперь это можно будет запретить компилятором.
источник

T

Tagir in pro.jvm
Tolegen Izbassar
А кто-нибудь из тех, кто любит final, занимался случаями, когда библиотека чего-то не учла? Вот прям по честному, когда нужно определенное поведение, которые авторы либ сочли "неправильным". Тут палка о двух концах.
Идёшь в трекер к авторам библиотеки и убеждаешь их, что для твоих целей нужно переопределить такой-то метод. Велик шанс, что желание переопределить всё равно кривое, и надо сделать по-другому. Автор сделает нормально, ты ему занесёшь донат, обновишь версию и будешь радоваться жизни
источник

TI

Tolegen Izbassar in pro.jvm
Tagir
Идёшь в трекер к авторам библиотеки и убеждаешь их, что для твоих целей нужно переопределить такой-то метод. Велик шанс, что желание переопределить всё равно кривое, и надо сделать по-другому. Автор сделает нормально, ты ему занесёшь донат, обновишь версию и будешь радоваться жизни
Ага. И ждешь полгода пока такой тикет поправят и выпустят)
источник

T

Tagir in pro.jvm
Такова цена опенсорса!
источник

T

Tagir in pro.jvm
Зажрались вы, сударь. Тридцать лет назад в каждой конторе свои велосипеды писали
источник

VP

Vladimir Petrakovich in pro.jvm
... а теперь только в каждой крупной
источник

TI

Tolegen Izbassar in pro.jvm
Ну в общем автор либы не может предсказать, как его либу будут использовать или какие юз-кейсы появятся. Он может ограничить расширение согласно своему видению, которое может не совпасть с реальностью. Как тут поступать в общем случае непонятно. Как всегда - множество переменных. Именно поэтому утверждать, что final всегда хорошо или наоборот смысла нет.
источник

TI

Tolegen Izbassar in pro.jvm
В одном случае - единственное решение действительно форкать и ехать вместе со своим велосипедом, в другом - писать авторам и донатить, в третьем - хачить.
источник

T

Tagir in pro.jvm
Tolegen Izbassar
Ну в общем автор либы не может предсказать, как его либу будут использовать или какие юз-кейсы появятся. Он может ограничить расширение согласно своему видению, которое может не совпасть с реальностью. Как тут поступать в общем случае непонятно. Как всегда - множество переменных. Именно поэтому утверждать, что final всегда хорошо или наоборот смысла нет.
Как поступать - я же сказал: общаться с автором либы. Если вы крупный клиент и заинтересованы в развитии, то контрибутить или форкать
источник

C

Cargeh in pro.jvm
Tagir
Как поступать - я же сказал: общаться с автором либы. Если вы крупный клиент и заинтересованы в развитии, то контрибутить или форкать
ты бы знал, как я офигел, когда после очередного релиза какой-то либы перестал компилиться код (пропали классы), я написал issue на гитхабе, сказал что мы этим пользуем и автор вернул классы!11!

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

C

Cargeh in pro.jvm
и мне кажется я не один такой скромный и стеснительный
источник

TI

Tolegen Izbassar in pro.jvm
Ну я бы предложил авторам либ не считать себя самыми умными и пытаться предсказывать, что пользователю может понадобиться, а оставить возможность расширения, даже если это идет в разрез с принципами. Большинство пользователей это делать не будут, а те кто будут, должны быть готовы, что все сломается и они сами себе буратины.
источник

TI

Tolegen Izbassar in pro.jvm
Если конечно мы говорим про либу, а не про фреймворк, который как-раз навязывает свою точку зрения всем пользователям.
источник

C

Cargeh in pro.jvm
Tolegen Izbassar
Ну я бы предложил авторам либ не считать себя самыми умными и пытаться предсказывать, что пользователю может понадобиться, а оставить возможность расширения, даже если это идет в разрез с принципами. Большинство пользователей это делать не будут, а те кто будут, должны быть готовы, что все сломается и они сами себе буратины.
тогда они будут считать себя самыми умными и пытаться предсказать, как именно пользователь будет расширять его либу - это тоже не всегда очевидно
источник

TI

Tolegen Izbassar in pro.jvm
Cargeh
тогда они будут считать себя самыми умными и пытаться предсказать, как именно пользователь будет расширять его либу - это тоже не всегда очевидно
да нет. просто не лепить final везде и все)
источник

VP

Vladimir Petrakovich in pro.jvm
Tolegen Izbassar
Ну я бы предложил авторам либ не считать себя самыми умными и пытаться предсказывать, что пользователю может понадобиться, а оставить возможность расширения, даже если это идет в разрез с принципами. Большинство пользователей это делать не будут, а те кто будут, должны быть готовы, что все сломается и они сами себе буратины.
Проблема в том, что каждую такую возможность расширения придётся поддерживать до конца жизни, или ломать совместимость. А пользователи не смогут понять, попадут ли они в ту группу, у которой всё сломается.
источник

VP

Vladimir Petrakovich in pro.jvm
Кстати, в котлине на эту тему есть хорошее решение
источник