Size: a a a

Scala User Group

2020 July 24

GD

Gleb Donets in Scala User Group
Oleg ℕizhnik
Здесь, конечно, много подножек автор сделал сам себе, и практически ни одна из них акки не касается
А можно подробнее?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Gleb Donets
А можно подробнее?
Я боюсь, что это выльется в дискуссию о том, почему в каждом конкретном случае был использован тот или другой подход\ тип и все аргументы будут ссылаться на неотскриншотенные части кода.
Поэтому, наверное, пока не будет доступа к исходному тексту, я воздержусь от критики
источник

GD

Gleb Donets in Scala User Group
Нет, ибо я сам не знаю, как правильно
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Ну для начала, я бы вырезал внутренний бехейвиор в отдельную функцию.
Есть ощущение, что внутри собственной обработки сообщений не используются уже ни sinkWorker ни один из httpWorker ов
Очевидно, сделать это было бы проще, если бы lastChunkIndex и ingestionEnded были бы порефакторены в аргументы функций.
Есть даже ощущение, что ingestionEnded - это "индикатор состояния", который опять же можно отрефакторить в раздельные бихейвиоры.

Далее не вполне понятно, почему для spawnHttpWorker такой сложный тип, часть функция каррирована, второй блок аргументов содержит аргумент, который функционально зависит от первого (context.self). Опять же -что делает обработка RegisterYourself , если ожидается, что worker не начнёт работы до этого сообщения зачем передавать ссылку на себя и в инициализации и в сообщении, и почему нельзя там же передать ссылку на Sink и исключить её из конструктора.

В третьих implicit BufferedSource выглядит очень сомнительно. Непонятно, какие методы внутри могут его имплиситно использовать. И зачем он нужен после того, как мы уже получили Iterator[In] кроме того, чтобы закрыть его в самом конце.

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

GD

Gleb Donets in Scala User Group
Oleg ℕizhnik
Ну для начала, я бы вырезал внутренний бехейвиор в отдельную функцию.
Есть ощущение, что внутри собственной обработки сообщений не используются уже ни sinkWorker ни один из httpWorker ов
Очевидно, сделать это было бы проще, если бы lastChunkIndex и ingestionEnded были бы порефакторены в аргументы функций.
Есть даже ощущение, что ingestionEnded - это "индикатор состояния", который опять же можно отрефакторить в раздельные бихейвиоры.

Далее не вполне понятно, почему для spawnHttpWorker такой сложный тип, часть функция каррирована, второй блок аргументов содержит аргумент, который функционально зависит от первого (context.self). Опять же -что делает обработка RegisterYourself , если ожидается, что worker не начнёт работы до этого сообщения зачем передавать ссылку на себя и в инициализации и в сообщении, и почему нельзя там же передать ссылку на Sink и исключить её из конструктора.

В третьих implicit BufferedSource выглядит очень сомнительно. Непонятно, какие методы внутри могут его имплиситно использовать. И зачем он нужен после того, как мы уже получили Iterator[In] кроме того, чтобы закрыть его в самом конце.

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

GD

Gleb Donets in Scala User Group
spawnHttpWorker - это вообще главная боль, ибо он должен был спавниться в контексте того актора, в который функцию его спавна передали, принимать извне функцию обработки запроса, и знать как об одном конце пайплайна, так и о другом
источник

GD

Gleb Donets in Scala User Group
"и почему нельзя там же передать ссылку на Sink и исключить её из конструктора"
А это мысль
источник

Y

Yevhen in Scala User Group
https://scastie.scala-lang.org/P7NeRGmsQsyw6rUHwbeRFA
как ету проблему лучше всего решить, нужно завернуть в враппер чтото з типами сделать?
источник

НМ

Никита Мязин... in Scala User Group
Метод copy автоматически генерируется для кейс классов, не для обычных классов или трейтов
источник

D

Denis Buzdalov in Scala User Group
источник

Y

Yevhen in Scala User Group
этот юз кейс утрирован конечно же
источник

D

Denis Buzdalov in Scala User Group
Yevhen
этот юз кейс утрирован конечно же
Тогда надо уточнять, что же именно хочется.
источник

Y

Yevhen in Scala User Group
хочеться copy вынести в трейт и чтобы кейс класы его имплементили
источник

D

Denis Buzdalov in Scala User Group
Yevhen
хочеться copy вынести в трейт и чтобы кейс класы его имплементили
Так в чём проблема? Добавьте метод copy в ваш трейт.
источник

Y

Yevhen in Scala User Group
в наследников кейс класов разные поля, соответсвенно разные аргументы в copy
источник

Y

Yevhen in Scala User Group
придеться перед копи патерн матч писать
источник

D

Denis Buzdalov in Scala User Group
Yevhen
в наследников кейс класов разные поля, соответсвенно разные аргументы в copy
то есть, вы хотите trait у которого будет расширяемое количество аргументов у одного из методов в наследниках? Как-то не по-скаловски, по-моему.
источник

Y

Yevhen in Scala User Group
https://scastie.scala-lang.org/vIKPI3GyRUOJViNAcvl1XA
вот такое разве решение нашел
источник

DZ

Dmitry Zuev in Scala User Group
сделай через тайпкласс
источник

Y

Yevhen in Scala User Group
можно со скасти примером плс
источник