Куда?

А в каком возрасте уже поздно на стажировки?

В таком возрасте когда признаков жизни меньше чем у морского огурца.

Куда?

ИТ, программирование, сейчас интересуюсь нечеткой логикой и объеденения ее с нейронкой и генетическими алгоритмами

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

Но это офтоп

В таком возрасте когда признаков жизни меньше чем у морского огурца.

Звучит как человек в коме ? Что вы имеете в виду под признаками жизни?

Звучит как человек в коме ? Что вы имеете в виду под признаками жизни?

Признаками жизни являются показатели состояния человеческого организма, позволяющие установить, что он жив.

Звучит как человек в коме ? Что вы имеете в виду под признаками жизни?

Это вот как неделя перед экзаменом, но несколько лет подряд. Не заморачивайтесь раньше времени :)

Она по-моему спрашивает о том, является ли сидение в котлин-чатике признаком жизни.

Не является. Можно печатать не приходя в сознание.

А иногда только на это сил и хватает. Но это действительно оффтоп.

https://github.com/JetBrains/kotlin/releases/tag/v1.3-M2

Кстати, есть ли какое нибудь обьяснение, почему нет интерфейса для объектов с componentN? Можно было бы очень классные вещи делать

Кстати, есть ли какое нибудь обьяснение, почему нет интерфейса для объектов с componentN? Можно было бы очень классные вещи делать

Например?

Кстати, есть ли какое нибудь обьяснение, почему нет интерфейса для объектов с componentN? Можно было бы очень классные вещи делать

Чтобы эти componentN можно было куда угодно накидать extension'ами, наверное

Еще бы полиморфизма к ним (что бы можно было говорить "мне нужен тип с componentN", неважно какой)

Кстати, есть ли какое нибудь обьяснение, почему нет интерфейса для объектов с componentN? Можно было бы очень классные вещи делать

Потому что фичи языка используют ключевое слово operator + специальное имя, это довольно логично.

Например?

Например Component<A, B, C>

Как Tuple<A, B, C>

Например Component<A, B, C>

опять туплов хотите

Тогда бы можно было утроить настоящий паттерн-матчинг, мапперы и всякие штуки для сериализации и иных манипуляций с дата классами

Как Tuple<A, B, C>

Ну сделай его датакласом

Ну сделай его датакласом

Ну допустим я хочу сделать функцию, которая проверяет, является ли второе поле стрингой со значением "1"

Ну допустим я хочу сделать функцию, которая проверяет, является ли второе поле стрингой со значением "1"

Ну а кто мешает ?

Если бы был интерфейс Component2<A, B> можно было бы сделать value.component2() == "1"

А так надо лезть в реылексию, хотя на самом деле все методы уже есть

Точно также всякое копирование

Или шифрование

Или маппинг

Если бы был интерфейс Component2<A, B> можно было бы сделать value.component2() == "1"

Так сделай так же для дата класса )

Так сделай так же для дата класса )

Т.е. для каждого дата класса заимплементить интерфейс, руками делегируя component1() = component1()?

Может еще toString руками написать и hashcode?

Зачем, если component1 тебе сразу вернёт то, что нужно ?

Ты желаешь экстеншн к классу data class SomeClass

И там дергаешь нужные тебе методы

Впрочем, можно сразу к полям )

Я хочу ко всем data class, рассматривая их как tuple

А тебя type erasure не смущает ?

А чем оно должно меня смущать?

Как ты собрался узнавать тип того, что вернёт component ?

Или работать как с Any ?

Как ты собрался узнавать тип того, что вернёт component ?

А типа дженерики на что?

А типа дженерики на что?

А type erasure ?)

А type erasure ?)

а вывод типов ?

Это не для jvm задача немного )

на уровне компилятора все ок

а вывод типов ?

Каким образом ?

data class User(name: String, email: Email) : Component2<String, Email>

class Triple<T, U, V> : Component1<T>, Component2<U>, Component3<V> ?

Каким образом ?

А при чем тут затираение, если проверка будет на уровне компиляции ?

И на этапе компиляции все известно?

class Triple<T, U, V> : Component1<T>, Component2<U>, Component3<V> ?

Бомба

class Triple<T, U, V> : Component1<T>, Component2<U>, Component3<V> ?

и так 22-а раза ???

И на этапе компиляции все известно?

Тогда почему бы не воспользоваться кодогеном ?

компилятор — и есть кодген

class Triple<T, U, V> : Component1<T>, Component2<U>, Component3<V> ?

Скорее так CompnentN<T1, ..., TN> : ComponentN-1<T1, ..., TN-1>

Тогда почему бы не воспользоваться кодогеном ?

Потому что я пишу на языке, в котором компилятор и так генерит componentN(), я просто хочу интерфейс для этого

Ну, если ты хочешь единое что-то для всего, ты утыкаешься в рантайм проблемы. Если ты заранее опишешь типы – чем использовать kotlinpoet хуже ?

Ну, если ты хочешь единое что-то для всего, ты утыкаешься в рантайм проблемы. Если ты заранее опишешь типы – чем использовать kotlinpoet хуже ?

Когда используешь листы, не натыкаешься на рантайм-проблемы?

Скорее так CompnentN<T1, ..., TN> : ComponentN-1<T1, ..., TN-1>

мне не нравится тем, что появляются bridge-методы ?‍♂️

Ну, если ты хочешь единое что-то для всего, ты утыкаешься в рантайм проблемы. Если ты заранее опишешь типы – чем использовать kotlinpoet хуже ?

я так и не понял зачем вам рантайм, мы хотим на уровне компиляции

Когда используешь листы, не натыкаешься на рантайм-проблемы?

Я в листах использую статическое количество дженериков и я не пишу методы для модификации данных внутри листа

Я пишу маппер функции, которые его модифицируют, задавая тип явно

Я в листах использую статическое количество дженериков и я не пишу методы для модификации данных внутри листа

да вроде variadic type parameters никто и не просит

Допустим, сгенерился интерфейс Component<T1,T2> Что с ним дальше делать ?) Мб я просто недопонял проблемы

Я в листах использую статическое количество дженериков и я не пишу методы для модификации данных внутри листа

так никто не коговорит про динамическое, посмотри в arrow, JOOQ

да вроде variadic type parameters никто и не просит

+

ERROR: S client not available

мне не нравится тем, что появляются bridge-методы ?‍♂️

Тогда мы затребуя Component2 не будем знать тип первого компонента(

Допустим, сгенерился интерфейс Component<T1,T2> Что с ним дальше делать ?) Мб я просто недопонял проблемы

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

Привет, а этим Triple или как-то иначе можно описать такой тип для json массива с разными типами данных ["string", 33, false]?

Массив фиксированной длины

ну, Triple<String, Int, Boolean>?

Допустим, сгенерился интерфейс Component<T1,T2> Что с ним дальше делать ?) Мб я просто недопонял проблемы

Ну например матчер для when, User.match("jakewharthon", Email("jw@gmail.com"))

И чем интерфейс лучше чем просто дата класс ?

И чем интерфейс лучше чем просто дата класс ?

даже и не знаю....

даже гугл не поможет

Отличное объяснение )

Отличное объяснение )

ну какой вопрос...

И чем интерфейс лучше чем просто дата класс ?

Интерфейсов можно имплементить много, а класс наследовать только один))

И чем интерфейс лучше чем просто дата класс ?

Тем что ты не сможешь сделать функцию match для всех data class не копируя ее как в go

Ты точно на котлине пишешь?

И чем интерфейс лучше чем просто дата класс ?

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

Ты точно на котлине пишешь?

походу ни начем не пишет

Ну например матчер для when, User.match("jakewharthon", Email("jw@gmail.com"))

придётся указать компонент, типа match3

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

+ создавать класс для "нового" тупла, нельзя наследоватся (вопрос нада ли)

придётся указать компонент, типа match3

Нуу, ad-hoc полиморфизм вроде бы в котлине никто не удалял

Может тогда стоит переюзать датакласс ?

Может тогда стоит переюзать датакласс ?

как ?

Может тогда стоит переюзать датакласс ?

Ты троллишь

как ?

Ну, если ты пишешь экстеншн к Component<String, Int> то это ничем не лучше, чем если ты сделаешь экстеншн к дата классу StringInt

Ну, если ты пишешь экстеншн к Component<String, Int> то это ничем не лучше, чем если ты сделаешь экстеншн к дата классу StringInt

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

А что за функцию ты хочешь написать для Component<T1, T2>, можно пример ?

Ну например матчер для when, User.match("jakewharthon", Email("jw@gmail.com"))

this

а теперь у меня есть функция, она принимает тупл, и что-то там делает, ей все равно что там реально за объект, ей важен интерфейс который предоставляет данный объект

а теперь у меня есть функция, она принимает тупл, и что-то там делает, ей все равно что там реально за объект, ей важен интерфейс который предоставляет данный объект

Что делает ?) Можно конкретный пример, первый пришедший в голову ?)

Что делает ?) Можно конкретный пример, первый пришедший в голову ?)

принемает тип где должен первым инт(ид)

принемает тип где должен первым инт(ид)

но этот пример не совсем удачный

То есть, ты в общем случае начинаешь упираться на тип, erasure всё сломает

То есть, ты в общем случае начинаешь упираться на тип, erasure всё сломает

почему ? мне известен интерфейс