Надо делать проверку на наследование а не на совпадение

то есть он понимает что это лист и из каких элементов

Котлин же подменяет типы списков на свои

Не понял. Вы тип можете передать с дженериком, но у реального листа в рантайме этого дженерика не будет.

кстати, да

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

просто я так понимаю type берется из параметра дженерика, и по нему нужно отдавать converter или null если этот converter не подходит к этому типу

и вот если у меня будут 2 converter для разных list

как поступить (

Ну нельзя дженерик в рантайме определить. Никак. Единственный способ - при создании вашего листа создать еще инстанс Class или KClass и тащить его с собой

Что собственно довольно нормальное решение, если это действительно нужно. Но в большинстве случаев, это можно обойти проверками на этапе компилляции

Собственно, в джаве для того type erasure сделано, чтобы народ гвозди микроскопами не забивал.

если у вас функция это какой-нибудь try/catch экспрешен, в каком случае вы всю функцию в экспрешен тоже конвертируете? или делаете body с return?

пардон, экспрешен на 5-10строк

Собственно, в джаве для того type erasure сделано, чтобы народ гвозди микроскопами не забивал.

Ну erasure для дженериков в джаве сделали скорее для двух целей: 1. Обеспечить обратную совместимость для collections и прочего. 2. Экономия памяти, так как без erasure с каждым экземпляром дженерик типа пришлось бы таскать ссылки на то, какими типами он параметризован.

Ну erasure для дженериков в джаве сделали скорее для двух целей: 1. Обеспечить обратную совместимость для collections и прочего. 2. Экономия памяти, так как без erasure с каждым экземпляром дженерик типа пришлось бы таскать ссылки на то, какими типами он параметризован.

На второе можешь даже не смотреть)

Собственно, в джаве для того type erasure сделано, чтобы народ гвозди микроскопами не забивал.

Шарп прекрасно и без стирания живёт.

Я читал довольно много разных статей на эту тему. Во многих местах довольно авторитетно написано, что type erasure - это вообще правильно. И довольно сильный резон тут есть. Мест, где реально надо таскать с собой стертый тип в природе очень-очень мало.

Фактически это нужно только если какая-то динамическая генержка есть. Я в этих случаях просто таскаю с собой Class и особых проблем не ощущаю

Я читал довольно много разных статей на эту тему. Во многих местах довольно авторитетно написано, что type erasure - это вообще правильно. И довольно сильный резон тут есть. Мест, где реально надо таскать с собой стертый тип в природе очень-очень мало.

Ага, особенно в перегрузках методов.

Вообще редкий кейс.

Option всем, парни.

Вообще не вижу проблемы. Я знаю, что мне часто хочется иметь self тип, но это уже не проблема erasure

Вообще не вижу проблемы. Я знаю, что мне часто хочется иметь self тип, но это уже не проблема erasure

Серьёзно? Не видишь проблемы с перегрузкой и maybe типами?

если у вас функция это какой-нибудь try/catch экспрешен, в каком случае вы всю функцию в экспрешен тоже конвертируете? или делаете body с return?

Если вопрос про писать ли fun some(args) = expression - то ответ да, это поощряется code style, будь то try_expression, when_expression etc

Не вижу. У меня огромный кусок кода как раз с перегрузкой и опционалами. Я правда их сейчас на котлиновские нулябли везде заменяю.

Серьёзно? Не видишь проблемы с перегрузкой и maybe типами?

Тоже не вижу. Self тип делается через f-bounded polymorphism.

Все делается, но выглядит не очень.

Тоже не вижу. Self тип делается через f-bounded polymorphism.

Ага, в стиле гошечки решение) Нет дженериков, поэтому займёмся кодогенерацией)

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

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

Сурово.

Ага, в стиле гошечки решение) Нет дженериков, поэтому займёмся кодогенерацией)

Ну не знаю, вполне прямолинейное решение. Стиль гошечки это использование письменности канадских аборигенов https://www.reddit.com/r/ProgrammerHumor/duplicates/688p46/they_arent_angle_brackets_theyre_characters_from/

Ну не знаю, вполне прямолинейное решение. Стиль гошечки это использование письменности канадских аборигенов https://www.reddit.com/r/ProgrammerHumor/duplicates/688p46/they_arent_angle_brackets_theyre_characters_from/

Решение то прямолинейное, но отдаёт вкусом говна.

Нужно 5 разных типов. Сделай 5 разных классов.

Скажем так, часто хочется, чтобы дженерики не стирались. Тем не менее в подавляющем большинстве случаев, можно обойтись и со стиранием. Код со стертыми дженериками заведомо лучше и недажнее, чем с реифицированными (ну если там все не сделана на unsafe cast), так что идея, что типы надо сохранять только без этого уже совсем никак мне кажется разумной.

Решение то прямолинейное, но отдаёт вкусом говна.

Ну не знаю, не пробовал :)

Ну не знаю, не пробовал :)

На джаве не писал никогда?)

Скажем так, часто хочется, чтобы дженерики не стирались. Тем не менее в подавляющем большинстве случаев, можно обойтись и со стиранием. Код со стертыми дженериками заведомо лучше и недажнее, чем с реифицированными (ну если там все не сделана на unsafe cast), так что идея, что типы надо сохранять только без этого уже совсем никак мне кажется разумной.

Я не вижу разницы в надёжности, вот убей просто.

На джаве писал и до сих пор пишу и нравится. Котлин нравится больше, но и родная джава вполне хороша.

Господа, плохо в ладах с синтаксисом, можете привести простой пример условия : " иначе - подтягивать привязку Родителя"?

Если код со стиранием, то все проверки заведомо делаются при компиляции. Если с реификацией, то скорее всего в рантайме.

Ифом можно принебречь

Скажем так, часто хочется, чтобы дженерики не стирались. Тем не менее в подавляющем большинстве случаев, можно обойтись и со стиранием. Код со стертыми дженериками заведомо лучше и недажнее, чем с реифицированными (ну если там все не сделана на unsafe cast), так что идея, что типы надо сохранять только без этого уже совсем никак мне кажется разумной.

Код со стёртыми типами ещё надёжней. В хаскелл, например, в рантайме вообще информации о типах нет. То есть, компилятор, после того, как все сигнатуры выведет и проверит, если всё ок, всё стирает нафиг и компилирует дальше :)

Если код со стиранием, то все проверки заведомо делаются при компиляции. Если с реификацией, то скорее всего в рантайме.

А в чём проверить всё при компиляции без стирания?) Это же как со стиранием, только без.

А в чём проверить всё при компиляции без стирания?) Это же как со стиранием, только без.

В целом плохая практика делать проверки типов в рантайме. А отсутствие стирания делает эту плохую практику проще в исполнении. Всякие instanceof и прочее.

Именно.

Хотя когда припирает, раздражает, что его нет.

Блин, пропустил слово. А в чём проблема проверить все типы при компиляции?

В том, что если типы проверяются при компилляции, то не важно стерты дженерики или нет.

В том, что если типы проверяются при компилляции, то не важно стерты дженерики или нет.

new T() сделай со стёртыми типами.

Зачем? хотим шаблонов?

Это уже не стирание типов, это совсем другая история

В шаблонах есть свой большой прелесть, но про них надо очень долго и усердно думать, а то получится C++.

new T() сделай со стёртыми типами.

для начала убеди компилятор, что у T есть конструктор по-умолчанию

для начала убеди компилятор, что у T есть конструктор по-умолчанию

class Foo<T> where T: new()

new T() сделай со стёртыми типами.

new T - c каким контрактом? Если есть представления, что делать с объектом, значит есть интерфейс, если нет представления - зачем писать такой код?

class Foo<T> where T: new()

а на джаве?

а на джаве?

Я не пишу на джаве.

Я не пишу на джаве.

ну говоришь же про джаву

или другой jvm язык

ну говоришь же про джаву

Я говорю про стирание типов, а не про джаву.

На саом деле все это довольно легко делаться при помощи фабрик. Ну да, будет 5 строчек дополнительного кода. И что?

Я говорю про стирание типов, а не про джаву.

ну а я тебе говорю, что new T() в jvm тебе мешает сделать нечто другое, не стирание типов

ну а я тебе говорю, что new T() в jvm тебе мешает сделать нечто другое, не стирание типов

Ок, что мешает? Невозможность задать сигнатуру конструктора?

Ок, что мешает? Невозможность задать сигнатуру конструктора?

невозможность ограничить тип наличием определенного конструктора

невозможность ограничить тип наличием определенного конструктора

Ок, ограничиваем констируктором по умолчанию.

Всегда.

Ок, ограничиваем констируктором по умолчанию.

ну ты не можешь это сделать в джаве, нет такого синтаксиса

Да не при чем тут джава

ну ты не можешь это сделать в джаве, нет такого синтаксиса

Мы не о джаве говорим, повторяюсь. Не о языке.

Я про спеку дженериков.

Мы не о джаве говорим, повторяюсь. Не о языке.

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

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

Ок, я тебя понял. 1+1 = 2. Спасибо за факт.

Синтакс тоже не при чем. Его довольно легко поменять

а я правильно понимаю, что работа с кастомными аннотациями в котлин возможна только с добавлением либы kotlin.reflect ?

т.к. когда я получаю аннотации метода, моих кастомных там нету

Что подразумевается по дкстомными аннотациями?

а я правильно понимаю, что работа с кастомными аннотациями в котлин возможна только с добавлением либы kotlin.reflect ?

Ну вот :( Рак пользовательских аннотаций и в Kotlin полез.

мои созданные аннотации annotation class Name

Ну вот :( Рак пользовательских аннотаций и в Kotlin полез.

даже проверить нельзя ?

я не сказал что это хорошо

рефлексия вообще такое себе

решение

Ну вот :( Рак пользовательских аннотаций и в Kotlin полез.

Почему рак, и что плохого?

Рефлекты для аннотаций не нужны

То есть нужен базовый рефлект, но он в ядре

Аннтоации должны быть использованы умеренно, но сами по себе они не плохи

Почему рак, и что плохого?

Если одним предложением: аннотации непрозрачны для программиста, особенно те, которые в рантайм обрабатываются. Если подробнее, то аннотируя что-либо, программист говорит: "давай ка, фреймворк, ты в этой точке свой код ещё прогони и сделай мне хорошо". Потом можно наловиться граблей и трудно исследуемых проблем из серии: "да какая ещё скотина эту аннотацию обрабатывает и как???"

без аннотаций лучше жили?))

аннотации хороши для метаданных, типа валидации

а для остального такая себе затея

роуты лучше с дсл писать

Во многих случаях рантайм аннотации вполне заменимы функциями высших порядков.

Если одним предложением: аннотации непрозрачны для программиста, особенно те, которые в рантайм обрабатываются. Если подробнее, то аннотируя что-либо, программист говорит: "давай ка, фреймворк, ты в этой точке свой код ещё прогони и сделай мне хорошо". Потом можно наловиться граблей и трудно исследуемых проблем из серии: "да какая ещё скотина эту аннотацию обрабатывает и как???"

Мне припекало, когда коллега использовал @Scheduled из спринговых, и каждое изменение параметров сопровождалось пересборкой приложения. Но все же не стоит всех под одну гребенку.

Мне припекало, когда коллега использовал @Scheduled из спринговых, и каждое изменение параметров сопровождалось пересборкой приложения. Но все же не стоит всех под одну гребенку.

Я про сам механизм. Вставил аннотацию и не можешь быть точно уверен, какой код её будет обрабатывать. Особенно в большом проекте, где, например, несколько ORM

Если одним предложением: аннотации непрозрачны для программиста, особенно те, которые в рантайм обрабатываются. Если подробнее, то аннотируя что-либо, программист говорит: "давай ка, фреймворк, ты в этой точке свой код ещё прогони и сделай мне хорошо". Потом можно наловиться граблей и трудно исследуемых проблем из серии: "да какая ещё скотина эту аннотацию обрабатывает и как???"

Я пожалуй в целом согласен. Аннотации хороши для валидации автодокументирвоания. Их избыточное использование - довольно вредная вещь. Меня вот Guice вообще бесит