GD
Здесь, конечно, много подножек автор сделал сам себе, и практически ни одна из них акки не касается
А можно подробнее?
Size: a a a
2020 July 24
Oℕ
А можно подробнее?
Я боюсь, что это выльется в дискуссию о том, почему в каждом конкретном случае был использован тот или другой подход\ тип и все аргументы будут ссылаться на неотскриншотенные части кода.
Поэтому, наверное, пока не будет доступа к исходному тексту, я воздержусь от критики
Поэтому, наверное, пока не будет доступа к исходному тексту, я воздержусь от критики
GD
Нет, ибо я сам не знаю, как правильно
Oℕ
Ну для начала, я бы вырезал внутренний бехейвиор в отдельную функцию.
Есть ощущение, что внутри собственной обработки сообщений не используются уже ни sinkWorker ни один из httpWorker ов
Очевидно, сделать это было бы проще, если бы lastChunkIndex и ingestionEnded были бы порефакторены в аргументы функций.
Есть даже ощущение, что ingestionEnded - это "индикатор состояния", который опять же можно отрефакторить в раздельные бихейвиоры.
Далее не вполне понятно, почему для spawnHttpWorker такой сложный тип, часть функция каррирована, второй блок аргументов содержит аргумент, который функционально зависит от первого (context.self). Опять же -что делает обработка RegisterYourself , если ожидается, что worker не начнёт работы до этого сообщения зачем передавать ссылку на себя и в инициализации и в сообщении, и почему нельзя там же передать ссылку на Sink и исключить её из конструктора.
В третьих implicit BufferedSource выглядит очень сомнительно. Непонятно, какие методы внутри могут его имплиситно использовать. И зачем он нужен после того, как мы уже получили Iterator[In] кроме того, чтобы закрыть его в самом конце.
В общем, складывается ощущение, что смешаны несколько подходов к инициализации( функции в конструкторе, имплиситы,стартовые сообщения) , каждый из которых привносит свой кусочек сложности, и если сфокусироваться на одном, или даже развести разные подходы по разным функциям, получилось бы проще
Есть ощущение, что внутри собственной обработки сообщений не используются уже ни sinkWorker ни один из httpWorker ов
Очевидно, сделать это было бы проще, если бы lastChunkIndex и ingestionEnded были бы порефакторены в аргументы функций.
Есть даже ощущение, что ingestionEnded - это "индикатор состояния", который опять же можно отрефакторить в раздельные бихейвиоры.
Далее не вполне понятно, почему для spawnHttpWorker такой сложный тип, часть функция каррирована, второй блок аргументов содержит аргумент, который функционально зависит от первого (context.self). Опять же -что делает обработка RegisterYourself , если ожидается, что worker не начнёт работы до этого сообщения зачем передавать ссылку на себя и в инициализации и в сообщении, и почему нельзя там же передать ссылку на Sink и исключить её из конструктора.
В третьих implicit BufferedSource выглядит очень сомнительно. Непонятно, какие методы внутри могут его имплиситно использовать. И зачем он нужен после того, как мы уже получили Iterator[In] кроме того, чтобы закрыть его в самом конце.
В общем, складывается ощущение, что смешаны несколько подходов к инициализации( функции в конструкторе, имплиситы,стартовые сообщения) , каждый из которых привносит свой кусочек сложности, и если сфокусироваться на одном, или даже развести разные подходы по разным функциям, получилось бы проще
GD
Ну для начала, я бы вырезал внутренний бехейвиор в отдельную функцию.
Есть ощущение, что внутри собственной обработки сообщений не используются уже ни sinkWorker ни один из httpWorker ов
Очевидно, сделать это было бы проще, если бы lastChunkIndex и ingestionEnded были бы порефакторены в аргументы функций.
Есть даже ощущение, что ingestionEnded - это "индикатор состояния", который опять же можно отрефакторить в раздельные бихейвиоры.
Далее не вполне понятно, почему для spawnHttpWorker такой сложный тип, часть функция каррирована, второй блок аргументов содержит аргумент, который функционально зависит от первого (context.self). Опять же -что делает обработка RegisterYourself , если ожидается, что worker не начнёт работы до этого сообщения зачем передавать ссылку на себя и в инициализации и в сообщении, и почему нельзя там же передать ссылку на Sink и исключить её из конструктора.
В третьих implicit BufferedSource выглядит очень сомнительно. Непонятно, какие методы внутри могут его имплиситно использовать. И зачем он нужен после того, как мы уже получили Iterator[In] кроме того, чтобы закрыть его в самом конце.
В общем, складывается ощущение, что смешаны несколько подходов к инициализации( функции в конструкторе, имплиситы,стартовые сообщения) , каждый из которых привносит свой кусочек сложности, и если сфокусироваться на одном, или даже развести разные подходы по разным функциям, получилось бы проще
Есть ощущение, что внутри собственной обработки сообщений не используются уже ни sinkWorker ни один из httpWorker ов
Очевидно, сделать это было бы проще, если бы lastChunkIndex и ingestionEnded были бы порефакторены в аргументы функций.
Есть даже ощущение, что ingestionEnded - это "индикатор состояния", который опять же можно отрефакторить в раздельные бихейвиоры.
Далее не вполне понятно, почему для spawnHttpWorker такой сложный тип, часть функция каррирована, второй блок аргументов содержит аргумент, который функционально зависит от первого (context.self). Опять же -что делает обработка RegisterYourself , если ожидается, что worker не начнёт работы до этого сообщения зачем передавать ссылку на себя и в инициализации и в сообщении, и почему нельзя там же передать ссылку на Sink и исключить её из конструктора.
В третьих implicit BufferedSource выглядит очень сомнительно. Непонятно, какие методы внутри могут его имплиситно использовать. И зачем он нужен после того, как мы уже получили Iterator[In] кроме того, чтобы закрыть его в самом конце.
В общем, складывается ощущение, что смешаны несколько подходов к инициализации( функции в конструкторе, имплиситы,стартовые сообщения) , каждый из которых привносит свой кусочек сложности, и если сфокусироваться на одном, или даже развести разные подходы по разным функциям, получилось бы проще
А. ок, спасибо. Логично, попробую применить к этому коду
GD
spawnHttpWorker - это вообще главная боль, ибо он должен был спавниться в контексте того актора, в который функцию его спавна передали, принимать извне функцию обработки запроса, и знать как об одном конце пайплайна, так и о другом
GD
"и почему нельзя там же передать ссылку на Sink и исключить её из конструктора"
А это мысль
А это мысль
Y
https://scastie.scala-lang.org/P7NeRGmsQsyw6rUHwbeRFA
как ету проблему лучше всего решить, нужно завернуть в враппер чтото з типами сделать?
как ету проблему лучше всего решить, нужно завернуть в враппер чтото з типами сделать?
НМ
Метод
copy автоматически генерируется для кейс классов, не для обычных классов или трейтовY
этот юз кейс утрирован конечно же
D
этот юз кейс утрирован конечно же
Тогда надо уточнять, что же именно хочется.
Y
хочеться copy вынести в трейт и чтобы кейс класы его имплементили
D
хочеться copy вынести в трейт и чтобы кейс класы его имплементили
Так в чём проблема? Добавьте метод
copy в ваш трейт.Y
в наследников кейс класов разные поля, соответсвенно разные аргументы в copy
Y
придеться перед копи патерн матч писать
D
в наследников кейс класов разные поля, соответсвенно разные аргументы в copy
то есть, вы хотите trait у которого будет расширяемое количество аргументов у одного из методов в наследниках? Как-то не по-скаловски, по-моему.
DZ
сделай через тайпкласс
Y
можно со скасти примером плс