- 1
List<Tuple4<Bayes, Bayes, Bayes, Bayes>> bayesResult = new ArrayList<>();-
Java / Говнокод #19136
−37
http://stackoverflow.com/questions/29970164/reuse-results-of-first-computation-in-second-computation
Запостил:
someone,
04 Декабря 2015
Follow us!
Конечно в данном случае тут пиздец под названием говноархитектура
Приведи пример.
У нас столько всяких функций вида fgetpos, которые возвращают некоторые свои аргументы через указатели, а можно было бы и явно.
И ещё любой код, в котором есть распаковка-запаковка
-- искусственное говно, которое породили из-за отсутствия возможности вернуть несколько значений.
это искусственное говно point.x, point.y, point.z гораздо удобней чем все x1 y1 z1 вместе взятые.
Мы рассматриваем только вырожденные случаи. Т.е. я предъявляю пример того, как кто-то активно работает с координатами в векторе, а мой виртуальный оппонент - пример того, как он реализовал алгоритм, использующий линейную алгебру. Мне удобно с множеством значений, ему - с объектами.
А может понадобиться и то, и другое. Нужна какая-то разворачивалка объектов:
(Только как быть с рекурсивными типами?)
Ты только что изобрёл паттерн-матчинг. В хаскеле и прочей функциональщине он примерно так и работает. Да, для любых ADT (структур), а не только унылых туплов, которые являются всего лишь частным случаем ADT.
А с рекурсивными типами расправляются... рекурсией. Один-два слоя снимаешь паттерн-матчингом, а дальше рекурсивный вызов.
Но он там "односторонний" - только в сигнатуре функции же?
x0 + (0, 0, z) в хаскеле и товарищах получится сделать? (где (+) :: Point -> Point -> Point)
Я не пойму, чем тебя x0 + Point(0, 0, z) не устраивает. Явный конструктор влом написать?
Да. Выходит как-то громоздко. Особенно, если структура сложная. Особенно, если ещё и new надо писать.
Наглядность пропадает; авторам библиотек приходится писать много разных конструкторов, конверторов и разных версий операторов.
Кстати, в JS new можно не писать, из-за чего можно ещё и ошибиться, описывая все эти new Point.
То полагаться на порядок полей в ней как-то страшно.
Я про структуру выражения, которое формируется для описания объекта.
А для сложных структур поможет наверно только JSON-подобная запись.
Кстати, для однородности и простоты парсинга имя класса (опциональное, но иногда нужное для однозначности) можно писать внутри скобок:
Вот бы можно было переопределить скобки и операторы:
optional, maybe, either, исключение в конце-концов. Но никак не тупл, в котором хуй поймёшь, где ошибка, а где значение...
Как будто что-то плохое...
Зато будет стимул документировать и возвращать какие-то разумные значения при ошибке, которые в некоторых случаях даже можно игнорировать.
Например, 0/NaN для sqrt(-1) и null для openFile.
Угу. Потому что по-хорошему для подобного отладочного вывода у Point'а будет toString() или operator <<. И тебе не понадобится 100500 раз изобретать вывод Point'а.
Это может быть как при создании класса:
1.1. a+b = (a.x+b.x, a.y+b.y) -- объект как набор полей при создании "атомарных" методов;
1.2. a-b = a + inv(b) -- объект как целое при компоновке существующих методов,
так и при использовании:
2.1. Point(x, y) -- объект как набор полей при конструировании;
2.2. x0 + Point(matrix[0][0], matrix[0][1]) или x + (0, 0, z) -- объект как набор полей при комбинировании разнотипных сущностей (сущностей из разных библиотек);
2.3. x + x0 -- объект как целое при работе с однотипными сущностями