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

V>Ты посмотри, сколько альтернативных решений напридумывали для одной и той же вещи.

А что в этом плохого? Вон сортировок тоже вагон существует, и для всех применение находится.

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

E>Кстати, а вы никак попроще не могли свою БД с текстами ошибок протестить, кроме как запуская основное приложение?

Ну QA так работало. Они все в комплексе тестировали. А у разработчиков с тестированием БД все нормально было.

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

P>А что в этом плохого? Вон сортировок тоже вагон существует, и для всех применение находится.

А что будет плохого, если будет встроенная в язык поддержка, которая будет оптимизироваться на уровне компиляции, и избавит от ненужной работы и поддержки разработчика?

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>При том, что вы будете, например, вычитывать эту табличку в структуру(класс), а там — byte, например.

Даже не смешно. 4-байтовое целое.

P>>Я слишком упростил. Там еще выставляют всякие параметры: уровень (info, error, warning), требуется ли реакция пользователя. Как это все в switch учесть?

YKU>Значит в коде этого не учтёшь, а в xml — учтёшь. Круто.

Я не говорил "в коде вообще". Я говорил "в switch". Внутри switch придется еще значения атрибутов сообщения руками выставлять. При числе сообщений ~100500 крайне тяжело их выставить руками, хоть в коде, хоть вне его. Но БД, по крайней мере, поправить можно, не делая лишний раз сборку из-за изменений в switch. А обработка, разумеется, делается в соответствующем методе.

YKU>Для этого в xml вставляются псевдооператоры, а когда и их не хватает — куски интерпритируемого кода... Мощь и гибкость, только xml, только хардкор!

Сталкивался с интерпретируемым кодом на XML, это не самое удачное решение. Но я где-то призывал его использовать?

YKU>Т.е. тестировщики тестируют непонятно что. И чем ваша ручная правка конфига отличается от партизанской замены dll, например?

Что значит "непонятно что". Им же не втихую подменяют измененные данные.

Да, а как все-таки многоязычный интерфейс-то поддержать?

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

P>Я не говорил "в коде вообще". Я говорил "в switch". Внутри switch придется еще значения атрибутов сообщения руками выставлять. При числе сообщений ~100500 крайне тяжело их выставить руками, хоть в коде, хоть вне его. Но БД, по крайней мере, поправить можно, не делая лишний раз сборку из-за изменений в switch. А обработка, разумеется, делается в соответствующем методе.

Интересно, а что за такая система, где вариантов сообщений 100500. Дайте пример прикладной задачи, где подобное существует.

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

E>Попробуй писать switch'и как-то так:

switch( code )
E>    case x1: {
E>        xxx;
E>        xxx;
E>        xxx;
E>    } break;

E>}

E>Что тут write only?

Так я гораздо больше читатель, чем писатель. Как, впрочем, большинство разработчиков. Таких switch-ей я видел не так уж и много. Обычно они длиннее, и каждый case, как правило, состоит более, чем их двух-трех коротких строчек. WndProc на голом WinAPI — тому подтверждение. Не просто так от switch внутри его всеми способами, начиная с MFC, стараются избавиться.

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

V>А что будет плохого, если будет встроенная в язык поддержка, которая будет оптимизироваться на уровне компиляции, и избавит от ненужной работы и поддержки разработчика?

А зачем ее встраивать в язык? Ее обеспечивает стандартный фреймворк или библиотека. В этом случае разработчик всегда сможет стандартную реализацию заменить собственной, если стандартная не подойдет, например, по результатам профилирования. Заменяли же зачем-то в старину встроенные функции PL/1 собственными, сделанными на Ассемблере.

Здравствуйте, Privalov, Вы писали:
P>А зачем ее встраивать в язык? Ее обеспечивает стандартный фреймворк или библиотека. В этом случае разработчик всегда сможет стандартную реализацию заменить собственной, если стандартная не подойдет, например, по результатам профилирования. Заменяли же зачем-то в старину встроенные функции PL/1 собственными, сделанными на Ассемблере.

Не понял, если была бы поддержка, то я бы тему не поднимал. Ибо сейчас каждый пишет как ему заблагорассудиться.

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

V>Не понял, если была бы поддержка, то я бы тему не поднимал. Ибо сейчас каждый пишет как ему заблагорассудиться.

Да и примеров этому куча. Возьмите любое IDE. NetBeans Idea Eclipse — по скольку они времени загружаются? Да шоб ушатались они блин...

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

P>Подобная работа с ошибками известна с давних времен.

P>А как поддержать иностранные языки с помощью switch? Так?

Так —

    switch (errorCode)
    {
        case 1:
           return ErrorEnum.Error1

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

V>>Будет интерфейс, а для нужного языка будет своя реализация.

P>И зачем на каждый язык отдельный релиз делать?

В Яве саттелитные сборки еще не придумали?

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

P>Внезапно выяснилось, что в языке нет define-ов. Ваши действия?
P>А если пользователь динамически языки переключает? Как тогда define-ы помогут?

Загрузка строк из language файла по строковым идентификаторам. Но не по числам.
Маппинг enum на строковый ID (он фиксирован, вне зависимости от языка) всё равно через switch.

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

P>Ну QA так работало. Они все в комплексе тестировали. А у разработчиков с тестированием БД все нормально было.

Ты как бы говорил о исключении сборки из цикла тестирований и исправлений. Мне не понятно почему нельзя было потестировать таблицу, как есть, яем сделать пересборку из-за ошибки в таблице достаточно маловероятной?

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

P>Так я гораздо больше читатель, чем писатель. Как, впрочем, большинство разработчиков. Таких switch-ей я видел не так уж и много. Обычно они длиннее, и каждый case, как правило, состоит более, чем их двух-трех коротких строчек.

Что мешает воспринимать каждый case, как отдельную локальную функцию
?

P>WndProc на голом WinAPI — тому подтверждение. Не просто так от switch внутри его всеми способами, начиная с MFC, стараются избавиться.
Главные причины там в другом... Во всяком случае AFAIK...

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

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

Тут есть 3 лагеря:

1. Велосепедисты.
2. Те просто кому не нравиться switch/case.
3. Так называемые "граммар-нацы". Экземпляры "aloch" и "Eye of Hell". Которые толкуют, что в стандарте Ц типа строки нету, есть класс std::string, CString ... QString





С такими приветами в общем. Вот тут беда, если подобные люди пишут стандарты. Я боюсь что будет дальше.

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

V>Да, только что проверил, NetBeans предлагает 7 жаву, только вот я не могу с пивом разобраться как создать проект на 7 жаве.

Это к меня уже проф деформация или проект это Тру , а 'javac helloworld.java' это не кошерно?

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

DC>Это к меня уже проф деформация или проект это Тру , а 'javac helloworld.java' это не кошерно?

Да просто без ИДЕ практически не работаю. Этой командой ни когда не пользовался.

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

V>Да просто без ИДЕ практически не работаю. Этой командой ни когда не пользовался.

Эта "команда" компилятор Явы

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

DC>Эта "команда" компилятор Явы

Вот типо не знали. Вы мне еще предложите код из текстового редактора писать.

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

E>Что мешает воспринимать каждый case, как отдельную локальную функцию
E>?

Например, такое:

switch (parms) {
    case 7:
       // обрабатываем 7-й параметр
    case 6:
       // обрабатываем 6-й параметр
    case 5:
       // обрабатываем 5-й параметр
    case 4:
       // обрабатываем 4-й параметр
    case 3:
       // обрабатываем 3-й параметр
    case 2:
       // обрабатываем 2-й параметр
    case 1:
       // обрабатываем 1-й параметр
        break;
    case 0:
           // что-то делаем
        break;
    default:
        break;
}

break встречаем только в самом конце. В остальных случаях он пропущен совершенно сознательно.
Да и потом, если мне в проекте нужно найти определенныю функцию или метод, с этим легко справляется любая IDE. А case-ы придется смотреть глазами. Их далеко не всегда пара-тройка, часто намного больше.