Здравствуйте, Cyberax, Вы писали:

C>Так не спорю. Только вот те сайтики, которые надо уметь делать, обычно делаются теми, кто не задаёт вопросов про нужность деревьев.
Все надо уметь делать. Можем о DDD порассуждать, о дизайне. Это тоже не просто.

C>>>Кстати, даже с сайтиком (простая внутренняя консолька для мониторинга) у меня потребовалось дерево. В одном месте там можно импортировать JSON и потом его экспортировать с изменениями. Чтобы порядок узлов не перекорёживался каждый экспорт — для карт используются бинарные деревья.
G>>Так он и так перекореживаться не будет. Вы посто добавляете новый узел в середку и все. Но это то о чем я говорил.
C>Так ещё и ликбез по хеш-картам надо проводить? Вау.

C>Подумай, что станет с порядком элементов в хэш-карте, если вставка элемента вызовет перебалансировку.
Слушай, что ты несешь?! Во что у тебя там превратилась простейшая операция импорта JSON? Бинарные деревья, хэш карты — какая то жесть бардовая! Вот вы всегда так безосновательно нагородите только потому что прочитали книжку по алгоритмам. Как этот код сопровождать потом?

Здравствуйте, Gattaka, Вы писали:

C>>Так не спорю. Только вот те сайтики, которые надо уметь делать, обычно делаются теми, кто не задаёт вопросов про нужность деревьев.
G>Все надо уметь делать. Можем о DDD порассуждать, о дизайне. Это тоже не просто.
Ну вот и порекомендую немного поучиться.

C>>Подумай, что станет с порядком элементов в хэш-карте, если вставка элемента вызовет перебалансировку.
G>Слушай, что ты несешь?! Во что у тебя там превратилась простейшая операция импорта JSON? Бинарные деревья, хэш карты — какая то жесть бардовая!
Вау. Такая безграмотность, да ещё и воинствующая!

Ну что же, урок информатики:

    public static void main(String []args) {
        final Map<String, String> map = new HashMap<>(2);
        map.put("one", "two");
        map.put("three", "four");
        map.put("can", "you");
        map.put("hear", "the");
        map.put("cannon", "roar");

        for(final Map.Entry<String, String> entry : map.entrySet()) {
            System.out.println(entry.getKey()+" "+entry.getValue());
        }
    }

Вывод:

can you
one two
cannon roar
three four
hear the

А теперь немного меняем:

    public static void main(String []args) {
        final Map<String, String> map = new HashMap<>(2);
        map.put("one", "two");
        map.put("five", "six");
        map.put("three", "four");
        map.put("can", "you");
        map.put("hear", "the");
        map.put("cannon", "roar");

        for(final Map.Entry<String, String> entry : map.entrySet()) {
            System.out.println(entry.getKey()+" "+entry.getValue());
        }
    }

И вывод становится полностью другим:

can you
five six
three four
hear the
one two
cannon roar

Это происходит из-за того, что внутри себя хэш-карта при вставках иногда перебалансируется, перемещая объекты между хэш-корзинами.

Если использовать хэш-карту для хранения узлов из JSON'а, то при небольших изменениях одного элемента можно получить diff размером в пол-файла.

Домашнее задание: описать в чём могут быть проблемы наивной реализации хэш-карты, если зловредный пользователь контролирует данные, которые в неё добавляются.

И дополнительный вопрос для школ с углублённым изучением информатики: почему в Java для объектов, помещаемых в обычные хэш-карты, всё равно имеет смысл реализовать интерфейс Comparable?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Gattaka, Вы писали:

G>>Я имею наглость спросить может это косяк? Просто предположение. Было у нас как-то соревнование между программистами нужно сделать было сервер по ТЗ. Так вот на NodeJS сделали его за час. C++ программиста за день не справились, т.к. надо ведь строчки парсить, кодировки мучать и пр. Начали писать свой nginx, в общем симптомы С++ налицо.

I>Это потому, что за вас уже сделали всю работу в самом Node.js — весь парсинг, обработка ошибок, асинхронщина и тд и тд. Все что надо — связать вместе.

Именно это я и пытаюсь до вас донести. Вся эта работа сделана и надо ей просто пользоваться.

Здравствуйте, netch80, Вы писали:

N>Боюсь, в таком варианте надо для надёжности вводить один класс с двумя функциональностями. Если не побьют за нарушение SRP.

Ну hashCode нужен гораздо реже, чем equals, поэтому, как мне кажется, лучше таки два.

N>>>Ну в плюсах есть такая возможность, но по умолчанию они используют таки стандартные сравнения.

vsb>>А что такое стандартное сравнение для MyClass? operator== вроде не генерится автоматом, т.е. для обычного класса не определены ни сравнение ни хеширование.

N>Тогда не скомпилируется. Стандартное — это то, что находится "естественным" поиском для a==b

Ну это по сути и есть интерфейс с утиной типизацией (или как там назвать по-умному такое). В Java утиной типизации нет, поэтому нужны явные интерфейсы, но идея такая же.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, netch80, Вы писали:

N>>Боюсь, в таком варианте надо для надёжности вводить один класс с двумя функциональностями. Если не побьют за нарушение SRP.

vsb>Ну hashCode нужен гораздо реже, чем equals, поэтому, как мне кажется, лучше таки два.

Для run-time hashCode нужен гораздо чаще.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, Gattaka, Вы писали:

G>>>Коллеги, создал голосование о необходимости выбора между binary tree и хэш таблицей. Если вы такой выбор осуществляли не могли бы вы описать код и ситуацию где это возникло.
C>>Постоянно нужно. Для нескольких целей:
C>>1) Запросы по диапазону ключей.
C>>2) Упорядоченный перебор.
C>>3) Подмножество пункта 2 — полностью воспроизводимые результаты. Т.е. чтобы два запуска с одними и теми же данными выдавали одинаковый результат.
G>Может лучше бы это делала база данных? Все равно вы до ее реализации не дотянете и будет хуже по производительности.

Apache Ignite-у это расскажи https://ignite.apache.org/

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Gattaka, Вы писали:

G>>Так он и так перекореживаться не будет. Вы посто добавляете новый узел в середку и все. Но это то о чем я говорил.
C>Так ещё и ликбез по хеш-картам надо проводить? Вау.

C>Подумай, что станет с порядком элементов в хэш-карте, если вставка элемента вызовет перебалансировку.

Ну вообще для этого есть LinkedHashMap.

Здравствуйте, anton_t, Вы писали:

_>Apache Ignite-у это расскажи https://ignite.apache.org/
Пусть для начала конторы, которые, с деньгами связаны это будут использовать. Банки, биржи, финансисты и пр. Там почему-то на эту ерунду даже и не смотрят.

Здравствуйте, anton_t, Вы писали:

C>>Подумай, что станет с порядком элементов в хэш-карте, если вставка элемента вызовет перебалансировку.
_>Ну вообще для этого есть LinkedHashMap.
Да, это более хороший вариант, если можно хранить его в своей системе. У меня он проходит через стороннюю систему, так что кроме дерева особо ничего не сделать.

Здравствуйте, anton_t, Вы писали:

G>>>Так он и так перекореживаться не будет. Вы посто добавляете новый узел в середку и все. Но это то о чем я говорил.
C>>Так ещё и ликбез по хеш-картам надо проводить? Вау.

C>>Подумай, что станет с порядком элементов в хэш-карте, если вставка элемента вызовет перебалансировку.

_>Ну вообще для этого есть LinkedHashMap.

Он хуже: в таком хранилище в случае удаления элемента и вставления заново (вполне возможный вариант при модификации) он попадёт в конец, а не сохранит исходную позицию.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, anton_t, Вы писали:

_>>Apache Ignite-у это расскажи https://ignite.apache.org/
G>Пусть для начала конторы, которые, с деньгами связаны это будут использовать. Банки, биржи, финансисты и пр. Там почему-то на эту ерунду даже и не смотрят.

Сбертех подойдет?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, anton_t, Вы писали:

G>>>>Так он и так перекореживаться не будет. Вы посто добавляете новый узел в середку и все. Но это то о чем я говорил.
C>>>Так ещё и ликбез по хеш-картам надо проводить? Вау.

C>>>Подумай, что станет с порядком элементов в хэш-карте, если вставка элемента вызовет перебалансировку.

_>>Ну вообще для этого есть LinkedHashMap.

N>Он хуже: в таком хранилище в случае удаления элемента и вставления заново (вполне возможный вариант при модификации) он попадёт в конец, а не сохранит исходную позицию.

Хуже-лучше это вопрос требований. Кейс, который ты описал, вполне может подойти под требования. Если, конечно, не наркоманить с удалением и вставкой ключа там, где можно обойтись обновлением значения, связанного с ключем.

Здравствуйте, anton_t, Вы писали:

_>>>Ну вообще для этого есть LinkedHashMap.

N>>Он хуже: в таком хранилище в случае удаления элемента и вставления заново (вполне возможный вариант при модификации) он попадёт в конец, а не сохранит исходную позицию.

_>Хуже-лучше это вопрос требований. Кейс, который ты описал, вполне может подойти под требования. Если, конечно, не наркоманить с удалением и вставкой ключа там, где можно обойтись обновлением значения, связанного с ключем.

"Наркоманией" является как раз насильный запрет варианта удаления и вставки ключа ради сохранения порядка там, где это сохранение естественно делается другими средствами.

Здравствуйте, anton_t, Вы писали:

_>Здравствуйте, Gattaka, Вы писали:

G>>Здравствуйте, anton_t, Вы писали:

_>>>Apache Ignite-у это расскажи https://ignite.apache.org/
G>>Пусть для начала конторы, которые, с деньгами связаны это будут использовать. Банки, биржи, финансисты и пр. Там почему-то на эту ерунду даже и не смотрят.

_>Сбертех подойдет?
Во-первых что за проект? Скорее всего это автоматизация внутреннего документооборота или регистрация времени работы сотрудников в офисе. Во вторых у них там Grid Gain кажется так называется. Купили какую-то мутную лабуду.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, anton_t, Вы писали:

_>>Здравствуйте, Gattaka, Вы писали:

G>>>Здравствуйте, anton_t, Вы писали:

_>>>>Apache Ignite-у это расскажи https://ignite.apache.org/
G>>>Пусть для начала конторы, которые, с деньгами связаны это будут использовать. Банки, биржи, финансисты и пр. Там почему-то на эту ерунду даже и не смотрят.

_>>Сбертех подойдет?
G>Во-первых что за проект? Скорее всего это автоматизация внутреннего документооборота или регистрация времени работы сотрудников в офисе. Во вторых у них там Grid Gain кажется так называется. Купили какую-то мутную лабуду.

Grid Gain — это коммерческая версия Apache Ignite. И название компании, которая разрабатывает Apache Ignite/Grid Gain.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, anton_t, Вы писали:

_>>>>Ну вообще для этого есть LinkedHashMap.

N>>>Он хуже: в таком хранилище в случае удаления элемента и вставления заново (вполне возможный вариант при модификации) он попадёт в конец, а не сохранит исходную позицию.

_>>Хуже-лучше это вопрос требований. Кейс, который ты описал, вполне может подойти под требования. Если, конечно, не наркоманить с удалением и вставкой ключа там, где можно обойтись обновлением значения, связанного с ключем.

N>"Наркоманией" является как раз насильный запрет варианта удаления и вставки ключа ради сохранения порядка там, где это сохранение естественно делается другими средствами.

Ты осознаешь, что это разные варианты порядка? В TreeMap мы имеем порядок, зазаваемый отношением порядка на ключе. А в LinkedHashMap имеем порядок, задаваемый порядком добавления значения в структуру, как в списке.
Это разные порядки и говорить какой из них абстрактно лучше, а какой хуже — бессмысленно.

Здравствуйте, anton_t, Вы писали:

_>>>Хуже-лучше это вопрос требований. Кейс, который ты описал, вполне может подойти под требования. Если, конечно, не наркоманить с удалением и вставкой ключа там, где можно обойтись обновлением значения, связанного с ключем.

N>>"Наркоманией" является как раз насильный запрет варианта удаления и вставки ключа ради сохранения порядка там, где это сохранение естественно делается другими средствами.

_>Ты осознаешь, что это разные варианты порядка? В TreeMap мы имеем порядок, зазаваемый отношением порядка на ключе. А в LinkedHashMap имеем порядок, задаваемый порядком добавления значения в структуру, как в списке.
_>Это разные порядки и говорить какой из них абстрактно лучше, а какой хуже — бессмысленно.

Безусловно, осознаю. Я говорил в контексте сообщения Cyberaxʼа, которое начало эту подветку. У него критически важным является сравнимость текстового представления без лишних перемещений ключей, цитирую:

C>> Если использовать хэш-карту для хранения узлов из JSON'а, то при небольших изменениях одного элемента можно получить diff размером в пол-файла.

И вот такое представление, при котором нет таких лишних перемещений, получается естественно и без лишних допущений — на TreeMap. И с несколькими дополнительными допущениями, которые могут быть проблемны — на LinkedHashMap: удалять ключи нельзя; читать из внешнего источника можно только слева направо (некоторые парсеры вполне могут сделать наоборот). Ну и совсем не получается — на просто HashMap

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, anton_t, Вы писали:

_>>>>Хуже-лучше это вопрос требований. Кейс, который ты описал, вполне может подойти под требования. Если, конечно, не наркоманить с удалением и вставкой ключа там, где можно обойтись обновлением значения, связанного с ключем.

N>>>"Наркоманией" является как раз насильный запрет варианта удаления и вставки ключа ради сохранения порядка там, где это сохранение естественно делается другими средствами.

_>>Ты осознаешь, что это разные варианты порядка? В TreeMap мы имеем порядок, зазаваемый отношением порядка на ключе. А в LinkedHashMap имеем порядок, задаваемый порядком добавления значения в структуру, как в списке.
_>>Это разные порядки и говорить какой из них абстрактно лучше, а какой хуже — бессмысленно.

N>Безусловно, осознаю. Я говорил в контексте сообщения Cyberaxʼа, которое начало эту подветку. У него критически важным является сравнимость текстового представления без лишних перемещений ключей, цитирую:

C>>> Если использовать хэш-карту для хранения узлов из JSON'а, то при небольших изменениях одного элемента можно получить diff размером в пол-файла.

N>И вот такое представление, при котором нет таких лишних перемещений, получается естественно и без лишних допущений — на TreeMap. И с несколькими дополнительными допущениями, которые могут быть проблемны — на LinkedHashMap: удалять ключи нельзя; читать из внешнего источника можно только слева направо (некоторые парсеры вполне могут сделать наоборот). Ну и совсем не получается — на просто HashMap

Зато LinkedHashMap сохранит существующий порядок ключей, а TreeMap может изменить его, получив "diff размером в пол-файла", которого опасается Cyberax.

Здравствуйте, anton_t, Вы писали:

C>>>> Если использовать хэш-карту для хранения узлов из JSON'а, то при небольших изменениях одного элемента можно получить diff размером в пол-файла.

N>>И вот такое представление, при котором нет таких лишних перемещений, получается естественно и без лишних допущений — на TreeMap. И с несколькими дополнительными допущениями, которые могут быть проблемны — на LinkedHashMap: удалять ключи нельзя; читать из внешнего источника можно только слева направо (некоторые парсеры вполне могут сделать наоборот). Ну и совсем не получается — на просто HashMap

_>Зато LinkedHashMap сохранит существующий порядок ключей, а TreeMap может изменить его, получив "diff размером в пол-файла", которого опасается Cyberax.

Если изначальный порядок уже был согласно TreeMap с тем же порядком ключей — то такого не случится. Думаю, он способен обеспечить такое входное условие, если уж заложился на качество диффа.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, anton_t, Вы писали:

C>>>>> Если использовать хэш-карту для хранения узлов из JSON'а, то при небольших изменениях одного элемента можно получить diff размером в пол-файла.

N>>>И вот такое представление, при котором нет таких лишних перемещений, получается естественно и без лишних допущений — на TreeMap. И с несколькими дополнительными допущениями, которые могут быть проблемны — на LinkedHashMap: удалять ключи нельзя; читать из внешнего источника можно только слева направо (некоторые парсеры вполне могут сделать наоборот). Ну и совсем не получается — на просто HashMap

_>>Зато LinkedHashMap сохранит существующий порядок ключей, а TreeMap может изменить его, получив "diff размером в пол-файла", которого опасается Cyberax.

N>Если изначальный порядок уже был согласно TreeMap с тем же порядком ключей — то такого не случится. Думаю, он способен обеспечить такое входное условие, если уж заложился на качество диффа.

Если он полностью контролирует входные данные, то да.