Или что-нибудь типа a.lift(x).flatMap(ar => val br = b.lift(x); if (ar != br) None else Some(ar))

Блин.

С композингом есть проблемы. Скажем придумали мы оператор &. Это значит что a.isDefinedAt(x) && b.isDefinedAt(x). Но от кого значение брать?

def &[A1 <: A, R1 >: A] (that: Extractor[A1, R1])(implicit m: Semigroup[R1]): Extractor[A1, R1]

Да, хорошее решение.

где-то для PartialFunction видел =>?

а ну вот она https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/package.scala#L125

из скалы выйдет прекрасный perl )

из скалы выйдет прекрасный perl )

Не надо путать грязный сахар на уровне синтаксиса и изящные решения на основе типов!

"Если нечто выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть." ))

Даешь безопасный typelevel perl в массы!

"Если нечто выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть." ))

Но это может быть живая утка, а может быть робот-утка.

Но это может быть живая утка, а может быть робот-утка.

Не ведись на очевидный тролинг)

или мимик

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

Не ведись на очевидный тролинг)

это не троллинг, это факты) я же не говорю, что плохо, а что хорошо - просто констатирую факты)

а ну вот она https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/package.scala#L125

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

это не троллинг, это факты) я же не говорю, что плохо, а что хорошо - просто констатирую факты)

это не троллинг, это унылый вброс, учитывая, что фактов было констатировано : 0

это не троллинг, это унылый вброс, учитывая, что фактов было констатировано : 0

это ты сейчас как-то уныло попытался парировать

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

не путайте, это запутанный символьный тайпалиас

это ты сейчас как-то уныло попытался парировать

это не парирование, я просто констатирую твой жир

не путайте, это запутанный символьный тайпалиас

ещё хуже

ещё хуже

на самом деле нет

можем вернуться к голосовалке про F против FooFunctor

typelevel perl это как известно линзы

(а typelevel lisp - фриманатки)

линзы очень даже легко читаются, если простые

хорошее уточнение :)

мне вот очень нравятся вот эти https://github.com/adamw/quicklens

линзы очень даже легко читаются, если простые

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

Друзья, а что читают хорошие люди про разруливание зависимостей в рантайме?

А что такое разруливание зависимостей?

IoC и DI что ли?

А что такое разруливание зависимостей?

Видимо декомпозиция задачи на мелкие и DI

А что такое разруливание зависимостей?

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

Вот собственно, есть ли книжки про разруливание и класслоадинг в таких ситуациях?

Во. Я все время говорю что такие ситуации это подавляющая анальная боль. А мне говорят, мол расслабься.

ну как выше писали, либо шадоуить, либо еще мерджить конфликты при assembly

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

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

ПРосто, чтобы знать.

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

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

jvm никак не разруливает. оно грузит в память что по порядку найдет

ага

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

ну как выше писали, либо шадоуить, либо еще мерджить конфликты при assembly

просто у меня нет понимания, как шейдинг спасёт, так как грузит мою библиотеку не java -jar а spark submit

поэтому я тебе и говорил почитай тредик

у меня трабла недавно была, Epoll постоянно терялся в тестах. Вылечилось тем, что я netty-epoll засунул выше библиотеки, которая затирала его..

там ужже разжевывали

я разобраться пытаюсь, а не проблему решить

читать пробовал?

полезно говорят

когда ты соберешь свою сборку A + C и зашейдишь в ней C, то ты получишь абсолютно новую сборку A + D ( и хоть D будет по сигнатурам идентичен C - это будет в другом пакете и следовательно на уровне jvm совсем другая библиотека, которая никак не будет конфликтовать с библиотекой C которую использует спарк)

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

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

если именно про класслоадеры хочешь) то есть даже пдфы; в гугл что-то типа jvm classloader pdf

только никто не решает эти проблемы через classloader

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

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

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

когда ты собираешь либу на плюсах, у тебя адреса в таблицах. когда ты собираешь .class - у тебя строчный литерал

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

Я только что написал эту книгу, ты будешь первым читателем

"О проблемах с класслоадерами в JVM" by Another Huy Глава 1. Как избавиться от проблем, когда две библиотеки тянут в зависимостях бинарно-несовместимые версии третьей библиотеки Никак. Конец

f

ERROR: S client not available

если ты собрал библиотеки под одну мажорную версию jvm - они не могут быть бинарно несовместимые в рамках jvm

если ты собрал библиотеки под одну мажорную версию jvm - они не могут быть бинарно несовместимые в рамках jvm

wut

Может имеется в виду мажорная версия скаловского компилятора?

Они всё равно могут быть бинарно несовместимы

сами по себе, безотносительно компилятора

сами по себе, безотносительно компилятора

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

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

да, но мы говорим о случае бинарной несовместимости

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

да, но мы говорим о случае бинарной несовместимости

давай определение бинарной несовместимости

я всего лишь спросил, что читают про класслоадинг (

давай определение бинарной несовместимости

A бинарно несовместима с B, если существует класс X одновременно в A и B, и байткод, использующий X, такой, что он может использовать версию X из A, но не версию X из B

пример, была версия либы 0.0.1-SNAPSHOT

Скалисты не хотят чистать про класлоадинг, они хотят писать библиотеки для json десериализации и вычитывание конфигов HOCON)

в ней был метод void foo(Int)

A бинарно несовместима с B, если существует класс X одновременно в A и B, и байткод, использующий X, такой, что он может использовать версию X из A, но не версию X из B

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

потом была версия 10.0.1

в ней депрекейченный метод foo был удалён

зато добавлен bar

есть две либы

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

другая- на версию 10.0.1, где используется метод bar

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

классическое название - dependency hell

deadly diamond of dependency hell

я всего лишь спросил, что читают про класслоадинг (

в разрезе твоей изначальной проблемы - "jvm грузит в память первый боди для класса со строковым именем "my.super.ClassName" который сможет найти" - это все, что критично-необходимо знать про класслоадинг. все остальные знания про класслоадинг - совсем из другой оперы

ну вот мне из другой оперы, я же еще раз

еще пишут

Senior Perl Developer https://moikrug.ru/vacancies/1000031282?f=telegram_b

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

возьмем библиотеку Lib. соберем одну версию, среди которых будет класс Utils с методом test и будем его использовать на равне с другими классами этой библиотеки. Соберем джарник и вырежем из него класс Utils. Соберем новую версию этой библиотеки и заменим там содержимое метода test. Запустим приложение и в итоге легко можем получить ситуацию, при которой все классы будут использоваться из первой сборки, а вот наш класс Utils может быть легко загружен из второй сборки. Таким образом будут использоваться обе версии сборки. 99% из первой сборки и 1% из второй - и они вполне могут выполнять интероп без всяких казусов

Senior Perl Developer https://moikrug.ru/vacancies/1000031282?f=telegram_b

скалистам начали эйчары по перлу писать? я же говорю - "из скалы выйдет прекрасный перл" - они видимо уже путаться начали)

возьмем библиотеку Lib. соберем одну версию, среди которых будет класс Utils с методом test и будем его использовать на равне с другими классами этой библиотеки. Соберем джарник и вырежем из него класс Utils. Соберем новую версию этой библиотеки и заменим там содержимое метода test. Запустим приложение и в итоге легко можем получить ситуацию, при которой все классы будут использоваться из первой сборки, а вот наш класс Utils может быть легко загружен из второй сборки. Таким образом будут использоваться обе версии сборки. 99% из первой сборки и 1% из второй - и они вполне могут выполнять интероп без всяких казусов

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

сделав то, что ты предложил, ты получишь на 99.99% говно