- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
switch (status) {
case "createInitRequest":
requestXml = ExtFunc.executeFreemarker(initReqTempl, null, values, em);
//values.put("soap", soap);
status = "signInitRequest";
//return;
case "signInitRequest":
initReqSoap = ExtFunc.signSoap(requestXml, context, em);
if (initReqSoap == null) return;
infomsg = "Запрос сформирован и подписан. Нажмите 'Продолжить' для отправки запроса.";
status = "preSendInitRequest";
//return;
case "preSendInitRequest":
status = "sendInitRequest";
return;
// далее ещё 20 кейсов, каждый из которых меняет значение status на значение следующего кейса
}
Follow us!
Ну а на самом деле конечно автора расстрелять и переписать все на SCXML (ввиду наличия редактора) потому что такое писать императивно это пздц, благо под джаву есть реализации SCXML от апаче.
зы: свич по стринге? В шестерке такого не было
разработчики: сан, сан, сан, ну что ты нам принес? Лямбды? Сахар для async?
сан: вот вам дети switch по строке
У него еще реализация прикольная и не требующая никаких изменений в jvm.
1) А она в жабе вообще есть?
2) Рандомизацию, емнип, пилят на уровне самого хешмапа, а не объектов, которые в него суют. Поэтому мешать не будет.
> Захардкоженный дикт, короче.
Угу.
hashCode должен иметь максимальный расброс, тогда хешмапа будет лучше работать. В вырожденном случае (hashCode == 42) всё свалится в одну ветку и будет такой лист с O(N)
Мы с s-a--m'ом говорим об атаке, когда злоумышленник, зная функцию хеширования, вынуждает сервер упихать большую часть ключей в одну корзинку дабы хешмапа выродилась в связный список и сдохла в мучениях.
Выродится в дерево. Не сдохнет.
TREEIFY_THRESHOLD = 8;
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/HashMap.java?av=f
Не будет.
Будет дерево с O(log(N))
Отвечу вопросом. А как же функционирует дерево?
В случае если хешкод будет всегда одинаковым, то для поиска нужного элемента всё равно придется проверить все элементы, а значит O(n), а значит разницы с листом никакой.
Вы наверное имеете ввиду что внутри-то там всё равно будет дерево, а не лист. Ну тут наверное можно согласиться)
>Зная хешкод, можно сразу пойти в нужную ветку и таким образом вызывать equals надо не для всех элементов в дереве, а лишь для её части.
А можно поподробнее?
is implementation provides constant-time performance for the basic operations (get and put), assuming the hash function disperses the elements properly among the buckets. Iteration over collection views requires time proportional to the "capacity" of the HashMap instance (the number of buckets) plus its size (the number of key-value mappings).
см. так же HashMap#get(). По хешкоду мы сразу идем в нужный бакет и уже там ищем нужный там элемент.
Речь идёт о функционировании дерева. Причём тут хешмап?
>В дереве данные разложены по веточкам.
На первом уровне ветки по hashCode, на втором -- по значению.
Если речь идет о TreeMap, то там и вовсе RBTree (как следует из названия)
Должна быть везде.
>2) Рандомизацию, емнип, пилят на уровне самого хешмапа, а не объектов, которые в него суют. Поэтому мешать не будет.
Я так и не понял, куда именно ее засунули, но ее смысл, чтобы удаленный пользователь не мог предсказать, у каких строк совпадет хеш.
И ведь лямбды тоже не повлияли на jvm. Ведь они всего лишь реализации интерфейсов с одним методом...
повлияло dynamic invoke (спасибо от имени всех пользователей грувей)
А из жабы оно доступно?
Это же для поддержки ЯПов без статики в JVM.
Кста в C# есть dynamic, он позволяет отказаться от статической проверки типов (рантаймовая проверка остается конечно). Думаю что он нужен чуть реже чем никогда.
Некоторые алгоритмы получаются намного короче и проще с dynamic. Тот же паттерн визитор. Или использование заранее неизвестных типов в рантайме. Но, учитывая отсутствие интеллисенса для динамики, усложнение рефакторинга, лучше использовать это только для прототипов, чтобы быстро получить результат. А потом переписать без dynamic.
А также dynamic сильно упрощает взаимодействие c COM (если это кому-то ещё нужно).
А не лучше ли для этого взять изначально динамический язык?
Нахуй.
Ага, хуй тебе. В 2020 выйдет.
Не все поцреоты руssкого мира с руssким языком знают термин "конечный автомат"?
>устоявшиеся термины
Где? На кабре?
Результатов: примерно 64 700 (0,29 сек.)
Результатов: примерно 278 000 (0,42 сек.)
А стейтмашина -- устоявшийся
Есть finite state machine. Есть конечный автомат. Зачем изобретать новую хрень, которая мало того, что кривая калька с английского, так еще и без finite...
Соглашусь с s-a--m'ом. Задрали уже все эти мерчандайзеры, супервайзеры, митапы и прочие воркшопы.
Миллионы мух не могут ошибаться?
> описании сетевых протоколов
> поведению разных компонентов PC, PCI master'а например
Если переводчик не знает терминологии и пишет "стейт-машина", то доверие к нему падает ниже плинтуса... Я лучше на английском прочитаю, ей-богу.
Оттуда он перекочевал в жаргон программистов. Никто не говорит "точка останова", "ловушка" (всмысле trap: эксепшен или фолт в IA-32), "отладчик" или "связывание", правда?
Из-за этого сраного жаргона у меня профдеформация - многие английские слова не могу правильно произносить :(
Имхо, если уж и использовать такие слова - так писать их латиницей, без уродской транслитерации, а читать - правильно.
> отладчик
Ну вот отладчик зря... Тут, вроде бы, большинство так говорит. И по исключению так же (эксепшн редко пишут).
P.S. А чем транслит то лучше? Как-то так надо по-вашему: "Когда я компилю мою апликуху кликнув шифт-ф10 в моем ИДЕ, я всегда думаю о том, что слова из манов на инглише лучше писать латиницей"? Ну для форума кулхацкеров - само то...
Транзлит выглядит не так глупо, имхо)
Ах нет, не имхо! Пмсм!
Вот это верно подмечено. Если читать статьи на сами знаете каком сайте, то можно прочувствовать всю боль ситуации. Одни делают ошибки из-за того, что они не специалисты в описываемых областях. Другие - узкоспециализированные авторы-профессионалы уже нужные термины знают, но, как и Кегдан, делают ошибки из-за того, что вертели они русский язык сами знаете на чём.
(Конечно, есть и промежуточные варианты, но крайности достаточно устойчивы, чтобы в них скатываться.)
Всмысле те, кто ни в русском языке ни в предметной области не силен?
Таких и правда предостаточно)_