Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+73
private boolean isAuthorized( ExecutionResult result )
{
Iterator<Long> accessCountIterator = result.columnAs( "accessCount" );
while ( accessCountIterator.hasNext() )
{
if (accessCountIterator.next() > 0L)
{
return true;
}
}
return false;
}
Человек написал книжку по програмированию :(
isbn:1449356265/9781449356262
Запостил: 
wvxvw,
24 Марта 2014
Follow us!
Судя по гуглу - в 2013.
В условиях же неиспользования библиотек и лишнего кода не вижу в прямом использовании итератора абсолютно ничего криминального.
Если речь о самом алгоритме проверки авторизации, то это, видимо, проявление уникальных преимуществ графовых баз данных.
Нет там такой. По идеологическим соображениям. Можно использовать ImmutableList.copyOf(), но это просто свинство по отношению к GC.
Скорее надо отрывать руки авторам API, возвращающих Iterator напрямую вместо Iterable.
Да, точно, их вроде просили, но они не сделали по идеологическим соображениям> отрывать руки авторам API
Тут на самом деле сложный вопрос. Если итератор тяжёлый и лениво подгружает записи из базы, то использование Iterator вместо Iterable создаст дополнительное препятствие пользователю, желающему обойти поток дважды (ResultSet же примерно так и работает).
С другой стороны, Iterator излишне усложняет код в типичных юзкейсах. Я бы сделал Iterable, но и дизайн с Iterator понять могу.
Жава головного мозга?
Если есть только итератор, любому индусу будет понятно, что дважды обойти коллекцию по этому итератору нельзя, хоть убейся.
Если есть iterable, то многократный обход коллекции не возбраняется.
>жаба ведет себя как девственница - "это хорошо, но это неправильно - потому откажу себе в удовольствии!"
У вас как тот самый случай со смесителем в канаде, где на каждом кране стоит одно и то же. Вроде и сделали из лучший побуждений, но на выходе такая хуйня получилась. Поцхему вы так не любите форич? Почему в питоне такой хуйни нет? Как же он обходится с возвратом результата из базы?
>A method to view an iterator as an iterable
>The biggest concern is that Iterable is generally assumed to be able to produce multiple independent iterators. The doc doesn't say this, but the Collection doc doesn't say this, either, and yet we assume it of its iterators. We have had breakages in Google when this assumption was violated.
Звучит правильно, но блядь, почему нужно все так усложнять? Почему нельзя, например, кидать исключение при попытке получить итератор второй раз?
> Почему в питоне такой хуйни нет? Как же он обходится с возвратом результата из базы?
А ты спеку-то открывал? Курсор-то не итератор, прикинь. Фетч надо явно дёргать.
А что с курсором не так? Он форыч поддерживает.
Да, ты прав. Посмотрел типичные драйвера, они в execute возвращают итератор.
Однако спека говорит:
> неужели посимпатичней никак нельзя?
Ну если очень хочется, никто таки не запрещает написать этот once самому
>никто таки не запрещает написать этот once самому
Риально удобно, риально падсибя? Почему все более-менее удобные обертки на яве - самопальные костыли?
пожалуй да
> Почему все более-менее удобные обертки на яве - самопальные костыли?
Потому что разработчики стандартной библиотеки на 95% наверняка необразованные индусы. Что поделать... Видимо, все умные люди пилят низкоуровневый хардкор.
Iterable - это такой результсет, указывает, что по нему можно итерировать, но сам итератор еще не готов
Iterator - собственно однонаправленный курсор, уже установленный в некоторой позиции.
таким образом, в первом случае мы можем лишь получить новый курсор (не считая других операций), а во втором - мы можем итерировать, но мы защищены от модификации.
как гибрид этих двух, еще ранее в жаве был реализован Enumeration, который был еще менее удобный в использовании.
> Почему все более-менее удобные обертки на яве - самопальные костыли?
взять, например, ту же спецификацию DOMv2
сарказм я обычно выделяю зелёным
Сорри, нужно было объяснить, что result сам по себе типа Iterable<Map<String,Object>> и итератор тут вообще не нужен.
А еще печально, что на дворе 2014, а в Яве нету стандартных any / find-if и т.д. А студентов продолжают обучать на этом говне под видом гениально спроектированых коллекций / контейнеров.
Вот как раз в 2014 появились
Над компиляторами разных лиспов работают полторы калеки в свободное от работы время, и тем не менее из динамических языков они самые быстрый код генерируют. Это в отличие от многотысячной армии на зарплате, которая пилит Ява виртуальную машину и компиляторы.
Кроме того, SBCL отнюдь не самый шустрый, зависит от архитектуры процессора, конкретной задачи и т.д. Арлекин писали самые лучшие лисповые компиляторы всегда, ну Аллегро тоже вроде хорошие. Rainer Joswig когда-то публиковал грид тест большинства известных реализаций. CCL гораздо быстрее обычно на АРМах, например. Но кроме того, есть куча вещей, которые эти тесты не учитывают, таких как что произойдет с програмой при наличии отсутствии определенных фич процессора, типа векторизации, СИМД, графических процессоров и низкоуровнего ПО которое с этим работает.
Более того, такие тесты учитывает только текущее состояние вещей. Например, в Яве только в последней версии попытались сделать распараллеленый сортинг. Все остальные стандартные алгоритмы - буй. Предположим, завтра Василий опубликует собственную явамашину в которой реализует все стандартные алгоритмы заточеными под Ксю - и специально напишет тест для хорошо параллелящихся алгоритмов, ну и получит соответствующую статистику.
Только вот CL говно не меньшее.
> в Яве только в последней версии попытались сделать распараллеленый сортинг
Параллельную сортировку можно было написать ещё на жабе 1.0. Продвинутые изкоробочные инструменты для fork-join алгоритмов появились ещё в 7 версии.
Как там, кстати, с тредами в анси стандарте девяносто лохматого года? Уютненько?
Но стоит упомянуть о говне в Яве, как начинаются предьявы к Лиспу и всякие обвинения, типа медлено работает слабо распространен и прочая херня не относящаяся к делу.
Да, в CL нету стандарного параллелизма, и это очень плохо. А в Яве параллелизм уебищный и не пригодна к повседневному использованию - и что лучше еще не известно. Однозначно понятно что и то и другое - плохо.
Хорошо было сделано в Оккаме, еще до появления говна типа Явы и С++, и все, что из этого следует, так это то, что Ява была написана бездараями, которые даже современные им технологии не осилили.
Да вам как не напиши - всё равно помяните нехорошим словом.
Года через четыре будет язык для работы с данными представленными графами, это при условии, что мое предложение рассмотрят на кафедре, найдется проф. которому оно понравится, и я таки смогу его написать, ну и заоодно может степень получить.
Предполагается найти хорошую систему записи правил двойного пушаута, по типу как в регулярных выражениях / пег. (это в том, что касается "запросов").
вот я, например, признаю, что я настолько идиот, что не осилил чистое ФП.
и да, объясните, пожалуйста, чем лисп так хорош?
офф: честно, лучше языка, чем JS (с некоторыми нюансами, я бы поправил) я не встречал. именно благодаря простоте и гениальной JSON нотации.
С другой стороны, когда мы уже знаем о существовании закономерности, и сталкиваемся с противоречием, дроблением, то переживаем прямо противоположные чувства.
JSON описывает очень мало структур данных, и еще меньше информации о них. Практически, все, что он дает это числа, обычный и экзотический (с символами) массивы и множество с операцией к другому множеству.
Даже об этих структурах можно было бы узнать больше непосредственно из записи. Например, какие-нибудь сведения о содержании массива, ограничивающие возможности интерпретации.
Можно было бы пожелать рекурсивные структуры, бесконечные структуры, структуры где, например, гарантировано, что граф ими представленый является планарным графом, или, с точки зрения инфорации о содержании, то можно было бы исследовать то, на сколько полно представлены допустимые элементы в коллекции, на сколько регулярно.
С практической точки зрения у JSONа есть несколько недостатков:
- нет комментариев.
- формат не поточный (чтобы распарсить, нужно прочитать все содержание).
- избыточная псевдографика в виде : и , (можно было ограничится пробелами).
- длинные строки без обрыва строки.
Разве?
>- избыточная псевдографика в виде : и , (можно было ограничится пробелами).
И забыть о форматировании.
я, кстати, тоже не вижу никаких проблем. Пулл парсеры готовые есть, читай потоком: вычитал два поля - выкини остальные.
Тут скорее проблема в том, что требуемые ресурсы заранее неизвестны - если бы длина и размер строк были известны заранее, парсинг шёл бы проще и быстрее, такую штуку засунули в BSON.
С другой стороны, писать BSON руками - мало приятного, а с JSON-ом всё ок.
Как бы не извращались в написании пулл-парсеров, они все равно будут говном, т.как нужно прочитать и распрарсить все без исключения данные для того, чтобы добраться до нужных данных.
> выкиньте остальные
камень же остынет! Потом разогревать снова!!!
BSON - только чуть-чуть лучше, но, опять же написан писателями, а не читателями, которые не удосужились даже прочитать, что остальные сделали. Но удача сопутствует смелым. А смелости, как правило, больше у людей без опыта :)
С JSON все ОК пока нужно решать задачи уровня крестиков-ноликов, как только задачи становятся сложнее, он вообще не пригоден. В качестве универсального формата данных - даже рассматривать бессмысленно.
универсальных форматов данных никогда не было и не будет. Как и универсальных языков программирования. Как и универсальных баз данных. Как и универсальных моделей.
Нам то всего-то нужна универсальность на столько, на сколько структур мы можем представить. А если мы можем их представить, то почему мы их не можем... представить?
Возможности представить структуру недостаточно. Мне сложно придумать структуру, которую невозможно так или иначе представить в json или xml.
Важны качества самого представления - насколько оно компактное, насколько его легко понимать без специальных инструментов, насколько просто написать парсер и вспомогательные инструменты, десятки противоречивых критериев. В зависимости от конкретной технической потребности оптимальными будут совершенно разные решения.
Даже из теплолампового архаичного программирования: нельзя представить связные списки, множества.
Из чего-то более нового, но не такого сложного: н-мерные латтисы. А как на счет геометрических фигур, а в 3+мерном пространстве?
Ситуация с современными форматами данных похожа не ситуацию, когда все люди - деревья выстроенные вдоль экватора, и таким образом не различающие лево / право и север / юг. Просто большинство довольствуется тем, что есть, даже не задумываясь о том, что то, что есть абсолютно не соответствует тому, что может быть.
> множества
> как на счет геометрических фигур
Семантика данных не прикремлена к самим данным, но это и не нужно. Если вам этого хочется, то напишите убер-схему и передавайте её вместе с данными.
> Просто большинство довольствуется тем, что есть
Большинство не выдумывает себе проблем до их появления и не ищут несуществующий Святой Грааль Форматов Данных И Всего На Свете (тм), который в результате 42.
Не представляет множество - как узнать нужно ли учитывать повторные элементы или нет?
А каким стандартом зарезервировано тег sphere, и где посмотреть все остальные зарезервированые, а как быть с S# (3+мерными сферами? тагов тоже бесконечное количество зарегистрировали? Как прочитать такой стандарт дальше буквы S?)
какое направление, акститесь, все односвязные списки одинаковой длины изоморфны. Бывают двусвязные, но не суть
> как узнать нужно ли учитывать повторные элементы или нет?
Очевидно, при чтении создавать множество и складывать туда элементы. А вот как узнать, что байты стрима не побились?
> А каким стандартом зарезервировано тег sphere, и где посмотреть все остальные
в урле xml-схемы в начале документа
> как быть с S# (3+мерными сферами?
добавить атрибут размерности, вложить координаты, в которых сфера существует.
Кстати, на досуге подумайте, насколько хорош ваш уберформат для передачи потокового видео на другой конец планеты.
А как узнать, что это то, что нужно делать? Я из формата этого не вижу. И ни однин человек без телепатических способностей этого не увидит.
> какое направление, акститесь,
Список - частный случай направленного графа (лоза), но направление у него никуда не пропало. Из вышеприведенной записи не понятно что с этой херней делать, опять же, если компьютер не телепат.
> добавить атрибут размерности, вложить координаты...
Где, в каком документе это описано? Кто об этом узнает не будучи телепатом?
И да, когда-то, много лет назад я работал в конторе которая вещала видео из бразильского казино в Европу :) Флешевый формат тогда создателям организации показался ненадежным, и они переписали обертку ФЛВ, мегаудобно подсибя. Я потом это реализовывал в клиенте этого... игрового сайта. И скажу вам откровенно, написав реализацию ФЛВ и Ф4В - там нет абсолютно ничего сложно, более того, эти форматы еще проще даже JSONа.
Придумать что-то такое - не то что выдающихся инжинерных способностей не нужно, вообще никаких способностей не нужно.
так они и должны быть проще жсона, я на это и намекал - нахрена семантика и валидация там, где важна скорость, простота и компактность?
Например, есть жизненная необходимость научиться нормально представлять изменения в СКВ, коммерческую информацию предприятия, музыкальные предпочтения брачующихся и желающихся забрачиться, влияние взаимного расположения аминокислот на эффективность лекарственных препаратов и т.д. И простота форматов типа JSON / XML тут выходит боком, потому что приводит к самопальным несовместимым, противоречивым, требующим специфического знания реализациям.
Одна из причин, по которым провалилась идея Веб3.0 - то что они выбрали в качестве универсальног формата ХМЛ, который просто не в состоянии справится с возложеной на него миссией.
Это то, что делает "бывших", куда бы они не иммигрировали, крайне правыми реакционерами-фундаменталистами.
> очень типично для граждан бывшего совка
>> А мне эти транзакции вообще не нужны. (c) http://govnokod.ru/15505#comment221945
.
Не, ну понятно, что для гигабайтов данных лучше юзать базу данных. На размерах до пары мегабайтов (пока все помещается в память) он работает - а это распространенный юз кейс.
Книжку написаную естесственным языком можно читать потоком не зависимо от того одна в ней страница, или стотысяч. ХМЛ нельзя читать потоком не важно, один таг из четырех символов или стотерабайтный файл.
А почему xml нельзя читать потоком? Ты с random seek случайно не путаешь?
учитывая что SBCL это даже не JIT, это что-то о моще Lisp'а все таки говорит.
ЗЫ колонка расхода памяти как всегда "радует".
разумеется, SBCL это даже НАТИВ (не всё так просто, но, во всяком случае, не исполнение байткода)
Подобная же фигня и с Erlang'ом. Он как бы официально интертрепатор, но многие случаи настолько соптимизированы, что интертрепативности и не видно.
Типизированная вьюшка колонки - вполне приемлимое решение. Только раз уж сам результат - Iterable, можно и вьюшку было сделать Iterable.
например, к boolean
Интуитивно, нужно приводить к общему самому широкому типу, но типы Лонг и Инт не ковариантны по-настоящему и не контраварианты. Поэтому "точного правильного" ответа в этой ситуации нет, если следовать хаскелеподобному выведению типов (в Яве оно такое же, но инструменты отличаются). Нужна другая парадигма, которая лучше описывает поведение програм.
На самом деле весь этот типобаттхёрт мне совершенно непонятен: в реальности проблемы с "ужасной" системой типов и "выразительностью" соотносятся со сложностями предметных областей, инфраструктуры, производительности и документации примерно как блоха на соседском коте и наблюдаемый участок вселенной.
Система типов в хаскеле почти никак не связана с жабьей, отличия колоссальные.
Ну из собственной практики проектирования библиотечного кода хочется собрать вместе и сжечь напалмом всех, кто считает, что сравнение значений разных типов и автоматическое приведение (даже типов с одинаковыми границами!) является чем-то хорошим.
Если кто-то считает, что неявно проверять в рантайме границы конвертируемости и кидать рантаймовые ошибки в случае косяков в системном коде - это хорошая идея, то не пойти ли бы ему в жопу с такими идеями.
Где система типов построена на тех же основаниях, но с принципиальными различиями: например в Эйфеле. Там методы могут быть коварианты в типах аргументов.
Где система в корне другая:
- нетипизированые языки, Форт, ПЛ и т.п.
- языки, где под "типом" подразумевается что-то совсем другое: J, Пролог, Эрланг, Лисп.
Статическая, да. А у лиспа, по такой логике, типизация такая же, как у питона, синтаксис такой же, как у XML, а мощность такая же, как у брейнфака.
Мощность такая же, как и у брейнфака, тут не поспоришь.
А можно поподробнее?
в хмле тоже можно в каком-нибудь сериализаторе объекты семантически зациклить, xml-то от этого бесконечно большим не станет.
Ну если брать только свойства, общие для хачкеля и жабы, а остальное игнорировать (а ведь при нормальных условиях в первом можно тоже много чего наопределять, чего нельзя во второй), то и лисповая становится питоновской!
В Питоне типизация такая же как в Яве / Хаскеле, с поблажками (когда система не в состоянии выразить тип, она его заменяет специальным типом "любой"). В Лиспе есть аналогичный механизм, но аналогичный механизм есть и в Яве и в Хаскеле. В Лиспе система качественно другая. В ней можно выразить типы которые нельзя выразить в Яве / Хаскеле / Питоне, и возможно, нельзя выразить что-то из Явы / Хаскеля / Питона.
Ну так покажите. Это вы заявили, что он там есть, а бремя доказательства лежит на утверждающем. В противном случае придётся с сожалением констатировать, что ваши разглагольствования про типы – бред.
Тут описана принципиальная разница между реализациями. Если у вас есть вопросы по реализации эквивалентного механизма в одном из языков - попробуйте сами его придумать, а лучше сначала в Гугл, там уже, как правило, есть.
А это что?
>А попытки упростить, типа как это сделано в Яве в итоге приводят к когнитивному диссонансу.
А в чем упрощение? Жава и другие языки проверяют на идентичность обьектов, если больше ничего не знают.
Ковариантность имеет смысл только для полиморфных типов. Long и Int к ним не относятся, так что они действительно ни те, ни другие, но я не понимаю, при чём тут вообще -вариантность.
всего несколько простых правил объясняют все:
1. расширение (примитивных) типов делается автоматически неявно
2. сужение типов требует явного каста, здесь легко отстрелить себе обе ноги с хуем заодно
3. арифметические операции неявно расширяют типы до "дефолтных" int и double, поэтому перемножить байты и присвоить байтовой переменной без явного каста не выйдет
4. объекты, в частности, обертки Int и Long, по equals сравниваются сначала по типу,
поэтому
> И даже Integer.valueOf(42).equals(Long.valueOf( 42)) вернет false.
5. и самое отвратительное: автоупаковка и распаковка типов, там вообще много интересных нюансов, которые любят спрашивать на экзах и собеседованиях
Вот если бы не она - все остальное было бы хоть и неудобным, но по крайней мере мало-мальски логичным.
А в плюсике вообще таятся стрингбилдер и неявный toString() ;)
Он самый. Декомпильни, если интересно ;)
Там тоже есть стрингбилдер, только он называется не так ;)
например, как реализован свитч по строкам :)
О да, это эпично...
Как отдельный анонимный класс с захардкоженным хешмапом, емнип.
Какая в жопу разница, какая там используется хеш-функция? Это же никак не влияет на работу хешмапа, кроме производительности.
P.S. Или ты подумал, что захардкожено = сохранено прям low-level представление этой мапы? Не, там че-то совсем банальное типа Map<String, Integer> заполняемого put'ами в статическом конструкторе.
Вот блин, то ли я лох и обосрался, то ли поменялся генератор кода в жабе... Может мне показалось, что там лишний класс генерился...
Сейчас скомпилил свич по строкам - действительно получился switch (str.hashCode()) и добивание коллизий ифами. hashCode() для String'а, емнип, в стандарте жабы прописан, и не может быть рандомизированным... http://docs.oracle.com/javase/6/docs/api/java/lang/String.html#hashCode%28%29
Свитч по строкам не нужен. Для больших размеров есть мапа.
Для маленьких - if.
Хешмеп-то захардкоженый.
http://www.benf.org/other/cfr/java7switchonstring.html
>hashCode() для String'а, емнип, в стандарте жабы прописан, и не может быть рандомизированным...
Как тогда атаку на хеш-коллизии лечили?
А ее лечили?
Ну могу предположить (не гуглил), что ее можно вылечить на уровне самого хешмапа, не трогая hashCode в 100500 классах. Для этого, походу, достаточно ксорить результат hashCode со случайным числом, сгенеренным при создании мапа.
На switch по строкам этот фикс не повлияет, т.к. там один хрен отдельная реализация. И ключи фиксированные и доверенные (т.к. вбиты в исходнике).
Это не убирает проблему подбора строк с равными хешкодами.
Если значения и типы только те, которые можно хранить на компьютере, то есть ;-) Но это ничего не даёт.
P.S. Но на самом деле я подозреваю, что термин «биекция» всего лишь был употреблён не в тему – примерно как «ковариантность» рядом.
Оооо, раскажите пож. как не в тему? А то с таким апломбом херню всякую пишут, ну ка, знающий человек, просветите.
Откуда возмется биекция, когда у одного значения есть 1 и больше типов?
Как обычно херня в защиту любимого языка, ничего нового.
Да, но я-то говорил про конкретные комповые, такие как вышеприведённые Int и Long, а в абстрактной теории типов свои тонкости, конечно.
> Откуда возмется биекция
Ну, тут всё просто – программ на компьютере счётное множество → представимых на компьютере значений и типов счётное множество → все счётные множества биективны по определению.
> когда у одного значения есть 1 и больше типов?
Для каждого натурального числа есть ваще дофига дробей, где она числитель, однако ж множества натуральных и рациональных чисел биективны ;-)
> А то с таким апломбом херню всякую пишут
Вот да, только в зеркало глянуть не забудьте.
Скорее – в защиту любимой науки, потому что нехрен выдумывать свои и подменять чужие понятия, это контрпродуктивно.
Ну и почему -вариантность не в тему, я уже в другом посте сказал. Так и в ситуации «для каждого значения может быть более одного типа, которому он принадлежит» (хоть это и совсем другая песня, и опять-таки зависит от аксиоматики, и к ЯП это имеет крааайне посредственное отношение) можно было так и сказать, а не приплетать математически некорректное (см. выше) здесь понятие, чтобы выглядело умнее.
> представимых на компьютере значений
Да ну? Какие же они счетные? Они же конечные.
Ну у каждого компа своя. А на самом деле комп даже не является машиной тьюринга, т.к. у него лента не бесконечна ;(
P.S. Ну ок, если считать компом машину тьюринга - то счетное.
любой комп способен не более, чем машина тюринга, сколько бы там лент или регистров не было (внешние устройства не учитываем)
все дискретные пространства счетны
если соотношение 1:1 - то это биекция
N:1 - сюръекция
1:N - инъекция, как раз
> отношение в Z2 {(0, 1), (0, 0), (1, 1)}
точнее, расширяй. либо пиши свои правила равенства, но ассоциативность необходимо сохранять
Пептиды — это добавки, состоящие из частиц аминокислот, они связаны путем амидных связей. проще — это «умные» белки, играющие самую важную роль в организме.