LINUX.ORG.RU

Где граница использования Generics?

 ,


0

2

Можно развести полное типодрочерство аля Haskell, написать классы по пять generic параметров. Только вот незадача, это не Haskell

API выглядят чрезвычайно красиво, несовпадающие параметры не возможны, но потом будет ряд проблем исходящих из субкультуры и verbosity Java

  • Большинство последующих программистов ничего не поймут когда захотят исправить баг, контингент не тот
  • Борьба с erasure
  • Скорее всего через время неосилившие начнут городить костыли по бокам через Object и касты

Где ваша граница? Ковариантность и контравариантность - это слишком на вашем проекте?

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

★★★★★

Последнее исправление: CYB3R (всего исправлений: 3)

Большинство последующих программистов ничего не поймут когда захотят исправить баг, контингент не тот
generics

Омг. Использую по мере необходимости, ни больше, ни меньше. Злоупотреблять смысла нет, но и лишать себя такого удовольствия не стоит.

f1xmAn ★★★★★
()
Последнее исправление: f1xmAn (всего исправлений: 1)

Ты специально пишешь глупости вроде «полное типодрочерство аля Haskell», чтобы опустить уровень дискуссии, или оно само собой получается?

anonymous
()

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

trashymichael ★★★
()
Последнее исправление: trashymichael (всего исправлений: 1)
Ответ на: комментарий от anonymous

Извини что обидел твой Хаскелль. Ты не комплексуй, нормальный язык

vertexua ★★★★★
() автор топика

Используй C++ templates - они вне всяких границ

nerdogeek
()

Чёткие пацаны по-прежнему сидят на J2SE 1.4 и не парятся.

CARS ★★★★
()

Чет не пойму как можно «перегнуть» с дженериками. Никогда не видел код на яве, где с этим проблемы. И да, если повыкидывать дженерики, как мне видится, вербосность только возрастет за счет постоянных кастов. Можешь пример кода привести?

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 1)

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

пример

class Func<A,V> {
  V apply(A arg);
}

public <A, V> List<V> map(List<A> list, Funct<A, V> func);

//В Коде

List<Integer> list =....
Func<Number, String> toStringFunc=...;

List<String> strings = map(list, toStringFunc);//хаха

Deleted
()
Ответ на: комментарий от Deleted

код где проблемы начинается с List<T>.add(Object aa)

Извини, но это не проблемы с темплейтами, а проблемы с дизайном, поскольку нельзя передавать в List с предопределённым типом в куда-то, где нет достоверной передачи объекта соответствующего типа.

С другой стороны, согласен - в жабе категорически не хватает ограничений на тип в шаблоне, типа List<T:JComponent>

no-dashi ★★★★★
()
Ответ на: комментарий от vertexua

Что значат две точки?

Что я быдлокодер и успел забыть синтаксис отдельных фич :-(

no-dashi ★★★★★
()

Если есть возможность, имхо, лучше писать поменьше всяких super extends и потом добавлять их по мере возникновения необходимости.

Ну и не надо стесняться использовать Object, на генериках мир клином не сошёлся и если код получается запутаннее, чем простые касты, которые все понимают, ну их нафиг.

Legioner ★★★★★
()

ИМХО, в Java дженерики, лямбды и пр. не нужны - только испортили ЯП, в том числе качеством нововведений

wota ★★
()
Ответ на: комментарий от Legioner

Выглядит угребищно, особенно на репозиториях. И у всех появляется желание делать God-классы для всех обьектов. Потом в них начинают появляться специализированные методы, вообще треш.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

Извини, но это не проблемы с темплейтами, а проблемы с дизайном

в kotlin темплейты есть а указанной проблемы - нет

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.