страшно представить как это выглядит в скале, есть пример?

(вынудил достать ноут) эт не совсем корректный вопрос, тк тайптеги и ко живут только в компайлтайме, тогда как котлиновская приблуда — только в рантайме обычно Class нужен не сам по себе, а для сравнения/подстановки куда-то тем не менее, вот: def foo[T]()(implicit ev: TypeTag[T]) = ev // достает тайптаг val tag = foo[String] tag.mirror.runtimeClass(tag.tpe.typeSymbol.asClass) // выковыриваем искомое, res9: Class[_] = class java.lang.String

тут принципиален вопрос лайфцайкла обоих вариантов

из доки котлина: Runtime-available types: String, Array<String>, List<*>; Non-runtime-available types: Nothing, List<String>, List<T> (for any T)

в скале же "ничего и не терялось" (с)

скажем, там можно провернуть def meth[A : TypeTag](xs: List[A]) = typeOf[A] match { case t if t =:= typeOf[String] => "list of strings" case t if t <:< typeOf[Foo] => "list of foos" } , что в котлине, как я понимаю, невозможно

(List[Foo] отличим от List[Bar] — внутренний тип выковыривается )

в Kotlin'e это сделано на таком уровне, что и читаемость сохраняется и функциональность дается (пусть и нельзя выковарять внутренний тип листа). Проблема решается для некоторых кейсов без каких-либо оверхедов на это решение после компиляции (путь и минимальных). Решение которое портируется и на java 6 без труда. Интересно то, что в сухом остатке TypeTag, как я понял (я вообще никак не работал со скала), это лишь метка, которая не может дать гарантий как и любое JVM приложение, что у тебя каждый элемент списка имеет тот самый тип "A", а значит по степени доверия это равносильно проверке типа у первого элемента.

это на вообще другом уровне гарантируется

ты же не будешь от List<Foo> ожидать, что там стринг внутри?)

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

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

бзв, тайптеги прекрасно работают на джава 6, без портирований

ты же не будешь от List<Foo> ожидать, что там стринг внутри?)

я не буду, но и гарантий я не имею) ровно как не имею гарантий того, что в списке строк не окажется Integer) я согласен с тем, что обычно так не делают, но это лишь подтверждает опасения, что для коллекций, например, TypeTag'и вообще не нужны, т.к. достаточно проверить тип первого элемента

я не буду, но и гарантий я не имею) ровно как не имею гарантий того, что в списке строк не окажется Integer) я согласен с тем, что обычно так не делают, но это лишь подтверждает опасения, что для коллекций, например, TypeTag'и вообще не нужны, т.к. достаточно проверить тип первого элемента

в смысле нет гарантий? оО

проверка типа-то в рантайме

патмат по нему, с тайптегом, определяется в компайлтайме

в этом как бы и фича)

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

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

мое регулярное обливание котлина грязью обьясняется в основном тем, что фичи "черрипикнуты" без оглядки на их взаимодействие в глобальном плане скала, внезапно, в ядре свом состоит из 2-3 ортогональных концепций, на которых строится "магия" (которая вовсе не магия) -- более целостный язык

это: реифайд дженерики, свичкейс, ко-контравариантность, экстеншн методы...

в смысле нет гарантий? оО

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

про "без оглядки на их взаимодействие в глобальном плане" не совсем понял. например?

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

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

мое регулярное обливание котлина грязью обьясняется в основном тем, что фичи "черрипикнуты" без оглядки на их взаимодействие в глобальном плане скала, внезапно, в ядре свом состоит из 2-3 ортогональных концепций, на которых строится "магия" (которая вовсе не магия) -- более целостный язык

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

про "без оглядки на их взаимодействие в глобальном плане" не совсем понял. например?

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

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

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

это называется "отсутствие гарантий". если в скале так нельзя, то снимаю шляпу public static void main(String[] args) { List a = new ArrayList(); a.add(1); List<String> s = a; for (String s1 : s) { //ClassCastException } } котлиновское решение в принципе не существует) т.к. в этом случае тип дженерика нельзч получить ровно как в джаве) это как бы намекает, мол, пс, парень, если хочешь узнать тип, хотябы проверь, что же внутри)

ну да, и для честности на jvm, в принципе, врядли реализуемы гарантии на уровне элементов

это называется "отсутствие гарантий". если в скале так нельзя, то снимаю шляпу public static void main(String[] args) { List a = new ArrayList(); a.add(1); List<String> s = a; for (String s1 : s) { //ClassCastException } } котлиновское решение в принципе не существует) т.к. в этом случае тип дженерика нельзч получить ровно как в джаве) это как бы намекает, мол, пс, парень, если хочешь узнать тип, хотябы проверь, что же внутри)

scala> val a = new java.util.ArrayList() a: java.util.ArrayList[Nothing] = [] scala> a.add(1) <console>:16: error: type mismatch; found : Int(1) required: Nothing a.add(1)

ты либо указываешь тип, либо компилятор (в меру своих мозгов) его выводит

где там моя шляпа

двигаясь дальше, с тайптегами — если тип списка дать как Any (почти Object, чуть шире, включает и примитивы), то проверка на равенство тайптега с, скажем, стрингом провалится

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

ты либо указываешь тип, либо компилятор (в меру своих мозгов) его выводит

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

это называется "отсутствие гарантий". если в скале так нельзя, то снимаю шляпу public static void main(String[] args) { List a = new ArrayList(); a.add(1); List<String> s = a; for (String s1 : s) { //ClassCastException } } котлиновское решение в принципе не существует) т.к. в этом случае тип дженерика нельзч получить ровно как в джаве) это как бы намекает, мол, пс, парень, если хочешь узнать тип, хотябы проверь, что же внутри)

Кстати, в Котлин такой код даже нельзя написать.

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

компилятор котлина вежливо просит определить тип и не компилирует)

ну, т.е. val c = ArrayList<Int>() - compiled, val c = ArrayList() - uncompiled

компилятор котлина вежливо просит определить тип и не компилирует)

ага, я о том же с Nothing тоже далеко не уедешь — у него нет сайбтайпов, "нижний тип" в иерархии логика вывода этого типа есть

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

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

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

макросы, которые scalareflect (это в компайлтайе в том числе, несмотря на название) — штука почти без ограничений, доступ к кишкам компилятора со всеми следствиями а макросы, которые scalameta, идея вполне себе переваривает вторые вытеснят первых в долгосрочной перспективе (в scala 3)

способна ли скала принять из Java List и при этом не проставить ему Nothing? подозреваю, что нет, но вдруг

способна ли скала принять из Java List и при этом не проставить ему Nothing? подозреваю, что нет, но вдруг

мм? там же тип указывается

в смысле, List<Foo> foos = ...

можно даже проще

аналогичный каст в скале пройдет? val a = ArrayList<Int>() a.add(1) val w = a as List<String>

макросы, которые scalareflect (это в компайлтайе в том числе, несмотря на название) — штука почти без ограничений, доступ к кишкам компилятора со всеми следствиями а макросы, которые scalameta, идея вполне себе переваривает вторые вытеснят первых в долгосрочной перспективе (в scala 3)

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

аналогичный каст в скале пройдет? val a = ArrayList<Int>() a.add(1) val w = a as List<String>

если это именно каст, типа (Foo)bar, то да, будет класскастэксепшн

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

на тайптегах можно написать свой "безопасный" каст (в примере выше оные никак не юзались)

на практике, за касты бьют по пальцам, в том числе и в джаве)

взаимно пора спать, действительно, спокойной ночи)

подскажите со стримами https://pastebin.com/9aebmeKR есть лист A надо получить лист B, сгруппированный по id c подсчётом сумм quant и передачей type от соответствующего id. Сейчас смог сделать так где type жестко зашит, как передать type соответствующий id

ERROR: S client not available

а вопрос то в чем?

как передать type соответствующий id в конечный лист

из class A в class B

dependent types не про java

что это за листоподобный язык?

https://www.youtube.com/watch?v=T-8fA3dEUlg

как передать type соответствующий id в конечный лист

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

вместо groupBy

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

и разбить на два стрима?

это уж как хочешь

спс

Начало в 11 как обычно?

Сегодня в 23:00 - 2:00 С 23:00 24 августа до 2:00 25 августа

збс

https://www.youtube.com/watch?v=Z2F-wZKbG8M

Collect(grouping, summing)?

Collect(grouping, summing)?

В чем вопрос?

Grouping, summing,mapping=)

Это ответ

))

чем выкатить голый джар в прод? докером просто? или как?

кстати очень незаслуженно проигнорированный вопрос. Мне бы тоже было интересно чем, товарищи, деплоите приложухи. Из того что я знаю: - war/ear - rpm,deb и иже с ними - docker - через scp и java -jar my-super-application.jar

что забыл?

кстати, а dev ops чатика нет?

DevOps — русскоговорящее сообщество Общаемся на темы DevOps, мониторинга, метрикам и облакам. Новости. См. также: @kubernetes_ru, @docker_ru, @rkt_ru, @coreos_ru, @ceph_ru, @openstack_ru Новости: @devops_news Вакансии и поиск работы: @devops_jobs Рекомендуем сразу отключить уведомления. https://t.me/devops_ru

@JBaruch через полчаса же?

почти началось) https://www.periscope.tv/razbor_poletov/1MYGNXLYVZOxw