ну средненький, для мейнстрима хороший, но в плане системы типов до хаскеля ему далеко конечно)

А Котлин — не нормальный?)

Говорят, котлин — это плагин.

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

нет

нет

Зачем вам тогда там sealed класс?

Много чего говорят. Только вот говорить "нормальный" о том, к чему ты привык — ну такое себе

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

ещё раз - это не я придумал, это нормальная практика в языках с которых Kotlin как раз и копирует концепцию sealed классов и data классов, с чего вдруг она неверная?

я к тому что в нормальных языках это делается нормально

Я все таки на уловил, чем тебя не устраивает None сделаный через object<Nothing> ? P.S. ну и Option это очевидное "не нужно" в котлине

И пытаться делать в одном языке так, как вы делали в другом — плохой тон. Надо делать так, как позволяет делать это текущий язык

Я все таки на уловил, чем тебя не устраивает None сделаный через object<Nothing> ? P.S. ну и Option это очевидное "не нужно" в котлине

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

ну средненький, для мейнстрима хороший, но в плане системы типов до хаскеля ему далеко конечно)

? ну ты сравнил (а вообще это и делает его мейнстримовые, в отличие от скалы)

И пытаться делать в одном языке так, как вы делали в другом — плохой тон. Надо делать так, как позволяет делать это текущий язык

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

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

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

? ну ты сравнил (а вообще это и делает его мейнстримовые, в отличие от скалы)

так это ведь даже было в котлине, и это не создавало бы никаких проблем абсолютно ни с чем, ни с изучением, ни с интеропом с джавой, ну просто вообще ни с чем, с чего депрекейтить-то?

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

Ну смотрите — вы такой один скорее всего на весь этот чат. Стоит этот депрекейт этого? Значит стоит)

Ну смотрите — вы такой один скорее всего на весь этот чат. Стоит этот депрекейт этого? Значит стоит)

оно бы кому-то помешало?

так это ведь даже было в котлине, и это не создавало бы никаких проблем абсолютно ни с чем, ни с изучением, ни с интеропом с джавой, ну просто вообще ни с чем, с чего депрекейтить-то?

Ещё, очень часто было сказано, что если у вас что-то не выходит на Котлин то вспомните, что это JVM язык.... напишите это на Scala, Java и тд

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

ну смотри, если я всё-таки захочу сделать так как хочу - вот в этом случае читабельность пострадает

Если его решили сделать депрекейтед, значит так решили. Котлин делает не два школьника после уроков, а за ним целая компания. Решили — надо. Но при этом успевают и к коммьюнити прислушаться

Объясните, почему вам это нужно и изложите красиво на гитхабе. Вдруг прислушаются (нет)

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

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

Затем, чтобы потом можно было сказать, что язык говно

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

да что там не очевидного-то?) что если data class Dummy(), то Dummy() == Dummy(), Dummy().toString == "Dummy()"?)

мне как раз кажется что это более очевидно, чем наличие какого-то немотивированного исключения из общего принципа ну да ладно

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

чтобы генерировался правильный equals и toString

очевидно же

конечно, я могу это руками сделать

только вот это выглядит как усложнение а не упрощение

разве нет?

чтобы генерировался правильный equals и toString

Если нет полей, то под что генерить?

ну я же всё написал уже

Dummy() == Dummy() всегда true

Dummy().toString() == "Dummy()"

Тогда вам в object классы или enum

Тогда вам в object классы или enum

объекты не могут быть полиморфными enum вообще мимо)

Можете сделать в сайлед классе базовые реализации

То строго это класснаме

Еквелс проверять класы

да могу-то конечно

И котлин не ломаете и вам неплохо

я же не говорю что нельзя в принципе это обойти

я просто ругаюсь на очень странно мотивированный депрекейт

который не упрощает а только усложняет

https://kotlinlang.org/docs/reference/data-classes.html

хотя вроде как само наличие возможности сделать так никому не мешало если кому-то эта фича не нужна была

Ну и в чем проблема, вам лень два метода написать?

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

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

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

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

А можно чела кликнуть

Ну и в чем проблема, вам лень два метода написать?

да я просто рефлексирую на тему "нахуя было депрекейтить"

Я не злой

Но если не нравится язык не юзай

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

Тогда вам в issue)

Тогда вам в issue)

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

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

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

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

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

Всем привет! Проводим в Ростове-на-Дону митап со свободным входом, есть возможность послушать о Kotlin от Романа Елизарова - первого, так сказать, лица :) Вход,повторюсь, свободный, угощаем пиццей и напитками ? Вся инфа здесь: https://vk.com/devexperts?w=wall-35463211_453

Господа, есть вопрос по форматированию. Есть какие-то правила для наличия/отсутствия отступа для полей или методов в классе.

эм, это как договоритесь в команде

Вкусовщина.

То есть стайлгайда по этому вопросу нет?

Ок.

Господа, есть вопрос по форматированию. Есть какие-то правила для наличия/отсутствия отступа для полей или методов в классе.

kotlin style guide?

Конечно же так class Example(private val digit: Int) { fun plus(x: Int): Int = dight + x fun minus(x: Int): Int = digit - x }

Конечно же так class Example(private val digit: Int) { fun plus(x: Int): Int = dight + x fun minus(x: Int): Int = digit - x }

Конечно же да, но это в этом конкретном случае. Если у тебя больше 2 строк кода, то так ты писать не будешь.

в kotlin style guide пустая строка требуется только если заголовок класса содержит несколько строк

class MyFavouriteVeryLongClassHolder : MyLongHolder<MyFavouriteVeryLongClass>(), SomeOtherInterface, AndAnotherOne { fun foo() {} }

Конечно же да, но это в этом конкретном случае. Если у тебя больше 2 строк кода, то так ты писать не будешь.

Ты меня плохо знаешь ?

Конечно же так class Example(private val digit: Int) { fun plus(x: Int): Int = dight + x fun minus(x: Int): Int = digit - x }

: Int лишние)

а еще лучше operator

: Int лишние)

если это библиотченый код и public, то я бы оставил тип. иначе при любом изменении в код после = поменяется api

если это библиотечный код то там будет интерфейс с явными типами

согласен ? но интерфейс не всегда возможен, из за того что нельзя final и inline

: Int лишние)

Да вот не знаю, хинты IDEA занимают столько же места. Не понятно в чем профит.

хинты выключить можно)

Да вот не знаю, хинты IDEA занимают столько же места. Не понятно в чем профит.

Есть сектанты, которые иногда открывают котлин-код вне идеи.

Есть сектанты, которые иногда открывают котлин-код вне идеи.

Ты чё кодревью делаешь? Оно для слабых

Да вот не знаю, хинты IDEA занимают столько же места. Не понятно в чем профит.

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

Ну такое, это же работает только в expression-functions. А вообще люблю конечно это дело в ML языках, там типы везде выводятся.

Ты чё кодревью делаешь? Оно для слабых

fun plus(x: Int): Int = dight + x даже не знаю как тут ревьювить без возвращаемого типа

Есть у нас какой-то изи способ быстро инпут стрим в массив байтов переделать?

fun plus(x: Int): Int = dight + x даже не знаю как тут ревьювить без возвращаемого типа

А upsource не умеет?

Есть у нас какой-то изи способ быстро инпут стрим в массив байтов переделать?

инпут стрим? Знаю что можно int[] -> byte[] перегнать через IntBuffer

InputStream.readBytes - есть такое в kotlin std lib

А upsource не умеет?

нет ?

нет ?

Вот это печаль

А upsource не умеет?

он зато в навигацию по коду умеет (но не всегда и не очень точно)

https://youtrack.jetbrains.com/issue/UP-7810

он зато в навигацию по коду умеет (но не всегда и не очень точно)

Я думал там под капотом из идеи двигло

На самом деле присоединился бы к вопросу касательно data class без полей, ибо сейчас у меня есть sealed class с пачкой наследников, часть из которых data-классы (надо сравнивать по полям), часть -- object-ы, и для последних .toString() выдаёт qualified name и instance id, которые выглядят так себе -- хотелось бы видеть MyClass() вместо com.example.company.project.package.MyClass@601d768d. Писать на каждый object ради этого .toString() лень.

Не то, чтобы это мешало решать задачи, как получается у @KolesnichenkoDS, но всё ещё.

создай обычный класс и переопредели equals и hashCode

class None : SomeSealedClass() { override fun equals(other: Any?) = javaClass == other?.javaClass override fun hashCode() = javaClass.hashCode() }