MD
Создавать для хранения результата каждого шага свой data class? Может есть ещё варианты? (И желательно, чтобы не было лишних копирований - при больших списках это накладно)
А создавать один объект с lazy полями - не вариант?
Size: a a a
2020 October 12
Ⓢ
Примерчик кода в студию, плиз )
ЮГ
А создавать один объект с lazy полями - не вариант?
Но ошибочное обращение к lazy тоже выстрелит только в рантайме. От nullable это отличается только отсутствием сейфколлов (или "мамойклянусь" !!)
MZ
Но ошибочное обращение к lazy тоже выстрелит только в рантайме. От nullable это отличается только отсутствием сейфколлов (или "мамойклянусь" !!)
Что такое "ошибочное"? бесконечная рекурсия?
MZ
А создавать один объект с lazy полями - не вариант?
годится только для тривиальных случаев, когда в общем-то никакого конвейера и нет.
видимо неявно предполагается, что для вычисления d нужен контекст, которого нет в том месте, где задаются (a,b,c). иначе какой же это конвейер - все значения можно вычислить сразу и всё
видимо неявно предполагается, что для вычисления d нужен контекст, которого нет в том месте, где задаются (a,b,c). иначе какой же это конвейер - все значения можно вычислить сразу и всё
MZ
Создавать для хранения результата каждого шага свой data class? Может есть ещё варианты? (И желательно, чтобы не было лишних копирований - при больших списках это накладно)
вроде неплохой же вариант с data class. во всяком случае он хорошо подходит для сложных кейзов, когда (a,b,c) задаются сильно отдельно от вычисления d. позволяет довольно шустро бегать по коду и искать места нужных вычислений. я бы так сделал
ЮГ
Maxim Zinchenko
Что такое "ошибочное"? бесконечная рекурсия?
Я имел в виду случай, когда обращаешься к неинициализированному lazy полю
MD
Я имел в виду случай, когда обращаешься к неинициализированному lazy полю
Оно не может быть не инициализированным, если оно не lateinit
MZ
Я имел в виду случай, когда обращаешься к неинициализированному lazy полю
это не так-то просто сделать. я как-то сходу не могу придумать как.
Ⓢ
Maxim Zinchenko
вроде неплохой же вариант с data class. во всяком случае он хорошо подходит для сложных кейзов, когда (a,b,c) задаются сильно отдельно от вычисления d. позволяет довольно шустро бегать по коду и искать места нужных вычислений. я бы так сделал
Происходит копирование полей, это плохо. И кода много лишнего
MD
Происходит копирование полей, это плохо. И кода много лишнего
Вкладывать объекты целиком? Копирования полей позволяет избежать, но вложенность становиться посильнее, конечно
MZ
Происходит копирование полей, это плохо. И кода много лишнего
каких таких полей? первый data class DC1(a,b,c). Второй data class DC2(dc1, d).
MZ
на самом деле даже если разбивать и собирать обратно - копирование указателей. я бы сказал это копьё
MD
Maxim Zinchenko
на самом деле даже если разбивать и собирать обратно - копирование указателей. я бы сказал это копьё
Ну, здесь уже повышаются издержки на любой рефакторинг, типа добавлять поля придется в n объектов
MD
Maxim Zinchenko
каких таких полей? первый data class DC1(a,b,c). Второй data class DC2(dc1, d).
Этот вариант выглядит предпочтительнее, канеш
MZ
Может быть ещё неочевидная сторона вопроса: в сложных сборках на Maven часто сталкивался, что «для нормального импорта проекта в IDEA нужно сначала сделать mvn install». Проблемы там из-за того, что какие-нибудь файлы генерируются во время сборки, и, соответственно, без них код красный.
В Gradle это можно настроить, и проект не просто импортируется сходу, но и IDEA показывает где исходники генерируемые, а где нормальные.
В Gradle это можно настроить, и проект не просто импортируется сходу, но и IDEA показывает где исходники генерируемые, а где нормальные.
это и так и не так одновременно.
если импортить с нуля и никак не настраивать проект IDEA, такое может быть, так как IDEA почему-то не всегда видит annotation processor, если про них речь.
но это всё довольно быстро настраивается, это проще чем при каждом изменении делать сначала maven сборку, потом ждать когда IDEA минут за 10 всё проиндексирует с нуля.
есть правда куча проблем с таким подходом - если скакать между ветками с сильными изменениями по списку модулей, нужно постоянно помнить про эту фигню и в случаях проблем лезть в список модулей и разруливать конфликты. но насколько я заметил эта проблема одинаково не решена ни для maven ни для gradle.
если импортить с нуля и никак не настраивать проект IDEA, такое может быть, так как IDEA почему-то не всегда видит annotation processor, если про них речь.
но это всё довольно быстро настраивается, это проще чем при каждом изменении делать сначала maven сборку, потом ждать когда IDEA минут за 10 всё проиндексирует с нуля.
есть правда куча проблем с таким подходом - если скакать между ветками с сильными изменениями по списку модулей, нужно постоянно помнить про эту фигню и в случаях проблем лезть в список модулей и разруливать конфликты. но насколько я заметил эта проблема одинаково не решена ни для maven ни для gradle.
MZ
Ну, здесь уже повышаются издержки на любой рефакторинг, типа добавлять поля придется в n объектов
с одной стороны да. с другой - контракт получается больно уж широкий. а почему собственно все последующие стадии должны знать всё о предыдущих? легко могу себе представить, что последующим стадиям нужно далеко не всё из предыдущих
MZ
попробуйте написать unit-тест для 10ой стадии, которая состоит в сложении x и y :) внезапно зачем-то понадобится конструировать тьму каких-то непонятных объектов, которые вообще никак не используются
2020 October 18
AL
Наткнулся случайно на относительно свежую статью о vertx в проде, оставлю здесь, вдруг интересно кому.
AL