У меня как раз всё нормально.
Это ты зачем-то сюда приписываешь режим обработки, как там сказано, "specified types of serious errors" — то есть типа нарушения памяти, причём не перехваченные(!) через SEH/VEH.
При чём тут кривое имя в операции открытия файла, если вообще вдруг надо проверяться (что ещё неизвестно)?
N>>Какой нафиг MessageBox? А если мы говорим о сервисе, который где-то в фоне? П>Если сервис — то просто молча падает.
"Молча"? Извини, но даже в Windows так не делается. Запись в журнал, пинок аудиту, попытка рестарта...
N>>По-нормальному так: ограничения или накладываются средствами FS, на уровне целой FS или каталога, или проверяются приложением добровольно в юзерленде. N>>Первое — так же как сейчас на стандартном виндовом разделе нельзя создать файл ABC если есть файл abc. П>Это ожидаемое поведение. Оно сто лет не меняется, и не собирается меняться (без приседаний)
Да хоть богами данное.
N>>Да, и вписать в хелпы где уместно — рекомендации посмотреть туда и применять. П>Или просто ничего не делать, что MS и сделала. Самое оптимальное.
Кто ничего не делает — тот не ошибается!
N>>Вот это — нормальный путь, а не безумные фантазии про MessageBox П>Окей, а теперь — как мне открыть файл, который уже содержит косяки в имени? Я 30 лет использую CreateFile, и всё работало, а тут возвращает ошибку.
Это через какое место надо читать, что я пишу, чтобы решить, что я такое предлагаю?
П> Думаешь, много людей догадаются перечитать все примечания мелким шрифтом в описании CreateFile?
О, теперь вдруг ещё и "мелким шрифтом"
П>Вообще-то, если ты пользуешься виндовыми функциями для работы с текстом, то такой ситуации и не возникнет — оно раньше сфейлится (или строка обрежется).
В каком из сценариев?
П>Прикрутить ICU и парсить имена в любом системном вызове, который принимает их на вход — у тебя что, винда слишком быстро работает?
У тебя. Потому что это твоё предложение, а не моё.
Серьёзно, я не понимаю, как надо было так читать, чтобы такое у меня вычитать...
Это, наверно, какой-то новый высочайший уровень нейтронной мегалоплазмы, мне до такого никогда не дотянуться...
The God is real, unless declared integer.
Re[15]: Почему dlang не обрел большой популярности?
N>Полностью исключены "я тут кусок соседа переформатировал, чтобы стало понятнее" и ответные вопли на ревью "да какого ж хера ты сюда лезешь, гад ползучий".
Первое решается запретом на переформатирование код. Но вообще любовь к такого рода занятиям распространена только среди тех, кому обязательно хочется "нанести всем пользу" — "сделать одинаково", "подстричь под одну гребенку" и т.п.. Кстати, "ответные вопли на ревью" при этом тоже отпадут. Кстати, устранение "наносителей пользы" (тех, что "я переформатирую код соседа, чтобы стало понятнее") само по себе хорошее дело. Чем раньше от таких "наносителей" избавиться, тем дольше компания сохранит функциональность.
N>Исключены споры типа "ставь два пробела".
Нет, все те же споры будут, просто на куда более серьезное уровне, занимая куда больше ценного времени.
N>Всем легче привыкнуть к "тут чуть-чуть неудобно" чем "одному удобно, а остальные воют".
Тоже неверно. Этот случай, когда "тут чуть-чуть неудобно", скорее исключение, чем правило. Правило же — когда 1-2 maintainer'а конкретного участка кода вынуждены ломать глаза об убогий форматтер. Реальность такова, что бОльшая часть кода существует во владении очень ограниченного количества людей. Заставляя их пользоваться форматтером, ты по сути заставляешь подавляющее большинство людей делать то, что удобно лишь одному (разработчику форматтера).
Особенно ярко это проявляется в том самом примере, что ты приводишь ниже, с uncrustify. У которого, если я тебя верно понимаю, гибкость настройки как раз отсутствует в силу того, что программист не осилил сделать reflow (что приведет к фатальным проблемам для многих отраслей, я позже напишу, как).
N>Всем снижать по чуть-чуть лучше, чем одному — радикально, и совсем лучше, чем если большинству — радикально.
Но происходит-то ровно наоборот. Всем радикально хуже, потому что их код теперь становится им же нечитаемым.
N>Если вообще осмысленно это переделывать, то лучше так:
N>
N>some_type_name first_var; //>! as viewed by frogs
N>some_type_name second_var; //>! as viewed by snakes
N>some_type_name third_var; //>! as viewed by herons
N>
Не знаю, чем это лучше, тут 3 строки вместо одной, и намного больше букв, чем это необходимо. Сие может быть оправдано если эти переменные являются частью какого-нибудь широко используемого класса. Но если это просто 3 переменные внутри крошечной функции с простейшей реализацией, раздувание строк и букв читаемость не улучшает. Зато может ухудшить рефакторинг, ибо явно добавлено копи-паста.
N>Обрати внимание — что настройка включается только в случае многострочного вызова. То есть foo(a, b) оно не переделает. Зато если не влезает на одну строку, то можно заставить переносить на следующую строку первый аргумент, выравнивая всех в столбик, а также писать каждый аргумент на отдельной строке. N>Причём обратное не форсируется, тут он не сворачивает принудительно в одну строку — для вызовов. А вот для объявлений функций — есть такая настройка.
Не форсируется? А можно ли включить это форсирование? Или беда-беда, потому что автор форматтера просто не в состоянии осилить алгоритм reflow? Спрашиваю, потому что вынужден был проходить через катастрофический пример корпоративного внедрения форматтера. Там катастрофа была не только потому, что корпорация, мягко говоря, не понимает, что делает, но еще и потому, что был бардак с менеджментом, который сказал "сделайте хоть как-нибудь, лишь бы одинаково". Ну и автор развернулся — сделал так, что форматтер противоречил существенной части принятых в языке конвенций.
Так вот, одна из алгоритмических проблем — сделать нормальный reflow, чтобы не было той самой беды, о которой ты выше написал. Разнести вызов (или определение) функции с одной строки на 15 может любой, простите, идиот. Но это реально проблема:
// что хочет форматтер
add_point(
x1,
y1,
z1,
x2,
y2,
z2,
alpha
);
// как оно должно быть
add_point(x1, y1, z1, x2, y2, z2, alpha)
// другой приемлемый вариант
add_point(x1, y1, z1,
x2, y2, z2,
alpha);
Лично мое мнение: если очень хочется форматтер, сделайте — но только такой, который не трогает переносы строки (и уж тем более не лезет с идиотскими ограничениями типа 80 или 90 или сколько там угодно символов на строку).
Сделайте проверку конвенций (типа наименования функций или переменных). Сделайте, наконец, пробелы между значками операций.
Но не трогайте переносы строки.
N>И в какой версии Java появился typedef?
Я специально использовал конструкции разных языков, чтобы было понятно — это не конкретный язык, а общее применение концепции.
Re[16]: Почему dlang не обрел большой популярности?
Здравствуйте, SkyDance, Вы писали:
N>>Полностью исключены "я тут кусок соседа переформатировал, чтобы стало понятнее" и ответные вопли на ревью "да какого ж хера ты сюда лезешь, гад ползучий".
SD>Первое решается запретом на переформатирование код.
Расскажи, как ты этот запрет будешь проверять _автоматизированно_.
SD> Кстати, устранение "наносителей пользы" (тех, что "я переформатирую код соседа, чтобы стало понятнее") само по себе хорошее дело.
Один раз переформатируют весь код в репозитории автоматом под выбранный стиль, далее таких "наносителей" просто не возникает.
SD> Чем раньше от таких "наносителей" избавиться, тем дольше компания сохранит функциональность.
Рассказываешь это на основании какого-то практического опыта, или так, фантазии с потолка?
Я-то на основании реальной практики рассказываю, за почти 10 лет ничего не "не сохранило функциональность", и это только самый характерный случай.
N>>Исключены споры типа "ставь два пробела". SD>Нет, все те же споры будут, просто на куда более серьезное уровне,
Это на каком именно и почему?
SD> занимая куда больше ценного времени.
N>>Всем легче привыкнуть к "тут чуть-чуть неудобно" чем "одному удобно, а остальные воют". SD>Тоже неверно. Этот случай, когда "тут чуть-чуть неудобно", скорее исключение, чем правило. Правило же — когда 1-2 maintainer'а конкретного участка кода вынуждены ломать глаза об убогий форматтер. Реальность такова, что бОльшая часть кода существует во владении очень ограниченного количества людей. Заставляя их пользоваться форматтером, ты по сути заставляешь подавляющее большинство людей делать то, что удобно лишь одному (разработчику форматтера).
1-2 maintainer-а это само по себе непорядок. Нормально хотя бы 3-4 — которые нормально в курсе происходящего. Но даже для двух полное совпадение стилей нереально.
SD>Особенно ярко это проявляется в том самом примере, что ты приводишь ниже, с uncrustify. У которого, если я тебя верно понимаю, гибкость настройки как раз отсутствует в силу того, что программист не осилил сделать reflow (что приведет к фатальным проблемам для многих отраслей, я позже напишу, как).
Ну напиши.
Гибкость у uncrustify как раз, по многим оценкам, даже избыточна. Аналоги вроде clang-format имеют в разы меньше настроек.
Uncrustify имеет другие проблемы — иногда он как-то странно подглюкивает по принципу "вот тут я теперь настаиваю вставить пустую строку", приходилось одобрять. Но вроде это залечили.
N>>Всем снижать по чуть-чуть лучше, чем одному — радикально, и совсем лучше, чем если большинству — радикально. SD>Но происходит-то ровно наоборот. Всем радикально хуже, потому что их код теперь становится им же нечитаемым.
Про "радикально" и "нечитаемым" — твоя эмоциональная оценка, к которой я не вижу реальных практических обоснований, зато вижу противоположное.
N>>Если вообще осмысленно это переделывать, то лучше так:
N>>
N>>some_type_name first_var; //>! as viewed by frogs
N>>some_type_name second_var; //>! as viewed by snakes
N>>some_type_name third_var; //>! as viewed by herons
N>>
SD>Не знаю, чем это лучше, тут 3 строки вместо одной, и намного больше букв, чем это необходимо. Сие может быть оправдано если эти переменные являются частью какого-нибудь широко используемого класса. Но если это просто 3 переменные внутри крошечной функции с простейшей реализацией, раздувание строк и букв читаемость не улучшает. Зато может ухудшить рефакторинг, ибо явно добавлено копи-паста.
Это не копипаста. Копипаста всеми средствами детектируется целыми строками.
N>>Обрати внимание — что настройка включается только в случае многострочного вызова. То есть foo(a, b) оно не переделает. Зато если не влезает на одну строку, то можно заставить переносить на следующую строку первый аргумент, выравнивая всех в столбик, а также писать каждый аргумент на отдельной строке. N>>Причём обратное не форсируется, тут он не сворачивает принудительно в одну строку — для вызовов. А вот для объявлений функций — есть такая настройка.
SD>Не форсируется? А можно ли включить это форсирование? Или беда-беда, потому что автор форматтера просто не в состоянии осилить алгоритм reflow?
Объясни, что ты понимаешь под reflow. Я пока вижу, что или оно там есть, или ты используешь это слово в каком-то неизвестном мне смысле.
SD> Спрашиваю, потому что вынужден был проходить через катастрофический пример корпоративного внедрения форматтера. Там катастрофа была не только потому, что корпорация, мягко говоря, не понимает, что делает, но еще и потому, что был бардак с менеджментом, который сказал "сделайте хоть как-нибудь, лишь бы одинаково". Ну и автор развернулся — сделал так, что форматтер противоречил существенной части принятых в языке конвенций.
Сдуру можно и хрен сломать, и что, это должно показывать проблемы форматтера? Или всё-таки глупость конкретной корпорации, которая могла проявиться в чём угодно другом?
SD>Так вот, одна из алгоритмических проблем — сделать нормальный reflow, чтобы не было той самой беды, о которой ты выше написал. Разнести вызов (или определение) функции с одной строки на 15 может любой, простите, идиот. Но это реально проблема:
SD>// что хочет форматтер SD> add_point( SD> x1, SD> y1, SD> z1, SD> x2, SD> y2, SD> z2, SD> alpha SD> );
SD>// как оно должно быть SD> add_point(x1, y1, z1, x2, y2, z2, alpha)
SD>// другой приемлемый вариант SD> add_point(x1, y1, z1, SD> x2, y2, z2, SD> alpha); SD>[/code]
SD>Лично мое мнение: если очень хочется форматтер, сделайте — но только такой, который не трогает переносы строки (и уж тем более не лезет с идиотскими ограничениями типа 80 или 90 или сколько там угодно символов на строку).
Именно uncrustify позволяет не трогать подобные вызовы — я приводил настройки в предыдущих комментариях.
Но если включить переформатировать их, то можно потребовать аргумент на новой строке всегда (мне тоже не нравится, но вдруг кому-то надо или только если уже многострочный вызов (а вот в этом уже есть польза). Жаль, что ты не хочешь читать, что тебе пишут.
SD>Сделайте проверку конвенций (типа наименования функций или переменных). Сделайте, наконец, пробелы между значками операций. SD>Но не трогайте переносы строки.
Можно. См. выше. Что дальше?
N>>И в какой версии Java появился typedef? SD>Я специально использовал конструкции разных языков, чтобы было понятно — это не конкретный язык, а общее применение концепции.
Так важнее случай, когда урезать таким образом длину строки не получается — и имена сложных типов Java как раз тому пример.
Поищи что-то другое.
Библиотеки — в них весь профит. Писать можно и на Си, но только если ты обвешан всеми мыслимыми либами. У Ди с этим крайне тухло. Сеть? Ничего даже рядом не стояло с каким-нть TcpClient или WebRequest (параша вроде vibe.d не в счёт). Хуже того — какой-то тупорылый самодур просто взял и выкинул удобный SocketStream и.... всё! Ничего не предложил взамен, просто выкинул. Дошло до того, что адекватный чел выложил undeaD — те самые удалённые модули! Ну как так можно похабно вести себя с библиотеками?!
Базы? Какая-то сторонняя приблуда, автор которой сам же пишет "она устарела". Стандартного нет НИЧЕГО, а ведь базы — это чуть ли не 50% рынка.
ГУЙ? Вообще удар по яйцам — у такого "классного" языка внезапно НЕТ ГУЯ! Не, разной степени паршивости врапперы есть, даже написали какое-то наколенное поделие вроде dlangui, но это явно не "ди-стиль" и спроектирована она плохо. Есть ещё просто "оболочки для Win32", но это всё не то. Нужна библиотека, полностью заточенная на возможности Ди(mixins, CTFE) и которая даст хотя бы гибкую базу, на основе которой уже можно клепать контролы. Ничего подобного нет — все заняты рисованием абстракций.
Что имеем в итоге? Даже новички с горящими глазами приходят, тыкаются во всё это наколенное фуфло и... уходят! А ведь новички и есть та ЦА, которая должна научиться писать на Ди и толкать его в массы. Одним авторитетом тут не обойтись.
И лично от себя, крайне раздражает синтаксис templates — неужели кроме круглых скобок ничего не нашлось?!?! На, блин, попрыгай в скобках, может чего поймёшь!
auto add(T)(T lhs, T rhs) {
return lhs + rhs;
}
Языки и так обвешаны всякими закорючками, а тут ещё и совпадающие символы! Это так "создатель Ди" ушёл от проблемы <> Будто в ASCII кончились все скобки и спец.символы.
В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
Re[2]: Почему dlang не обрел большой популярности?
Здравствуйте, Baiker, Вы писали:
B>Языки и так обвешаны всякими закорючками, а тут ещё и совпадающие символы! Это так "создатель Ди" ушёл от проблемы <> Будто в ASCII кончились все скобки и спец.символы.
В ASCII — кончились.
Круглые скобки при шаблонном типе это нормально и да, лучше, чем кошмар с <>.
Можно было бы заглянуть в юникод, но и туда много скобок не завезли.
Я не помню, в каком это языке сделали в стиле List(of Integer)?
Конечно, можно наворачивать всякие List<*Integer*>List<%Integer%>List%(Integer), но как бы не оказалось ещё хуже.
B>Библиотеки — в них весь профит. Писать можно и на Си, но только если ты обвешан всеми мыслимыми либами. У Ди с этим крайне тухло. Сеть? Ничего даже рядом не стояло с каким-нть TcpClient или WebRequest (параша вроде vibe.d не в счёт). Хуже того — какой-то тупорылый самодур просто взял и выкинул удобный SocketStream и.... всё! Ничего не предложил взамен, просто выкинул.
Ссылку в студию на выкидывание. Наверняка ж было какое-то обоснование.
B>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
B>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
гуй — это не фундаментальная либа и в языке она быть не обязана.
Ни в С ни в С++ никакого гуя нет, именно в языке, то есть в стандарте языка.
Кстати и остального там тоже нет (или не было до недавнего времени).
Re[3]: Почему dlang не обрел большой популярности?
Здравствуйте, CRT, Вы писали:
B>>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
CRT>гуй — это не фундаментальная либа и в языке она быть не обязана.
Для старта начиная с 2000 (а не 1972) таки очень желательно.
Заодно это позволяет оценить и показать реальный подход языка в определённых условиях — гуй очень специфичен по сравнению с кучей других задач, например, спецификой, которая ложится на классический трёхкитовый ООП.
CRT>Ни в С ни в С++ никакого гуя нет, именно в языке, то есть в стандарте языка.
Есть MFC, есть Qt, есть wxWidgets, есть десяток других. А про стандарт вроде никто и не говорил.
CRT>Кстати и остального там тоже нет (или не было до недавнего времени).
Легко находилось и подключалось.
The God is real, unless declared integer.
Re[4]: Почему dlang не обрел большой популярности?
B>>>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
CRT>>гуй — это не фундаментальная либа и в языке она быть не обязана.
N>Есть MFC, есть Qt, есть wxWidgets, есть десяток других. А про стандарт вроде никто и не говорил.
Как никто не говорил? Сказано было "В языке ОБЯЗАНЫ быть фундаментальные либы "
Сторонние либы это не "в языке". В языке это в стандарте.
Re[3]: Почему dlang не обрел большой популярности?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Baiker, Вы писали:
B>>Языки и так обвешаны всякими закорючками, а тут ещё и совпадающие символы! Это так "создатель Ди" ушёл от проблемы <> Будто в ASCII кончились все скобки и спец.символы.
N>В ASCII — кончились.
Фигня, не кончились! Даже Немерл прекрасно обошёлся <[ ]> — почему нет? А есть ещё ┤├, ◄ ►, и чем чёрт не шутит — даже негритёнок! ☻ В том смысле, что дженерик имени вовсе не обязательно быть В СКОБКАХ, достаточно какого-нть префикса (типа @). Да и проблема <> больше надумана. Ну кто будет сравнивать классы "больше — меньше"??? Для грамматики < > — вообще не помеха, не стоило с этим вообще заморачиваться. Вон, C# — прекрасно работает и в ус не дует.
B>>Библиотеки — в них весь профит. Писать можно и на Си, но только если ты обвешан всеми мыслимыми либами. У Ди с этим крайне тухло. Сеть? Ничего даже рядом не стояло с каким-нть TcpClient или WebRequest (параша вроде vibe.d не в счёт). Хуже того — какой-то тупорылый самодур просто взял и выкинул удобный SocketStream и.... всё! Ничего не предложил взамен, просто выкинул.
N>Ссылку в студию на выкидывание. Наверняка ж было какое-то обоснование.
Было! Не поверишь, "я это выкинул, потому что концепция SocketStream не вписывается в наше модное течение "всё есть ranges". Всё. На вопрос "а где тогда сокет на диапазонах??" ничего не ответила золотая рыбка — лишь на**** послала. Искать лень, было в рассылках (собственно, я и инициировал запрос). Наткнусь — обязательно приведу. Факт тот, что уже готовый И ИСПОЛЬЗУЕМЫЙ функционал ФИЗИЧЕСКИ выкинули из библиотеки, не дав вообще ничего взамен! Просто статус deprecated — был, но зачем сам класс убирать?? Просто пусть лежит годами, а когда будет замена — уберут. Такого безобразного резания библиотеки не видел вообще ни у кого.
Re[3]: Почему dlang не обрел большой популярности?
Здравствуйте, CRT, Вы писали:
CRT>Здравствуйте, Baiker, Вы писали:
B>>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
CRT>гуй — это не фундаментальная либа и в языке она быть не обязана. CRT>Ни в С ни в С++ никакого гуя нет, именно в языке, то есть в стандарте языка. CRT>Кстати и остального там тоже нет (или не было до недавнего времени).
Очередной мамкин спорщик? Ты приложения как писать собрался? Для каждого проекта заново делаем все фундаментальные библиотеки?
И где я сказал, что они должны быть в языке? Как всегда — сам себе придумал, сам оспорил, сам победил? Не интересно, иди спорь сам с собой.
Re[3]: Почему dlang не обрел большой популярности?
B>>>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
B>И где я сказал, что они должны быть в языке?
Здравствуйте, CRT, Вы писали:
CRT>Здравствуйте, netch80, Вы писали:
B>>>>В языке ОБЯЗАНЫ быть фундаментальные либы — гуй, сеть, базы. Без них в мэйнстриме делать просто нечего.
CRT>>>гуй — это не фундаментальная либа и в языке она быть не обязана.
N>>Есть MFC, есть Qt, есть wxWidgets, есть десяток других. А про стандарт вроде никто и не говорил.
CRT>Как никто не говорил? Сказано было "В языке ОБЯЗАНЫ быть фундаментальные либы "
CRT>Сторонние либы это не "в языке". В языке это в стандарте.
Ну всё, уцепился к слову и всё, твой оппонент повержен? Твой тухлый спор бесполезен, ты не привносишь ничего нового, а ПО СУТИ проблемы — просто выдал пук.
Re[4]: Почему dlang не обрел большой популярности?
Здравствуйте, Baiker, Вы писали:
B>>>Языки и так обвешаны всякими закорючками, а тут ещё и совпадающие символы! Это так "создатель Ди" ушёл от проблемы <> Будто в ASCII кончились все скобки и спец.символы.
N>>В ASCII — кончились.
B>Фигня, не кончились! Даже Немерл прекрасно обошёлся <[ ]> — почему нет?
Вельми дякс, запишу в копилку. Но это громоздковато, по 2 символа с каждой стороны, ещё и регистр дёргать вверх-вниз.
B> А есть ещё ┤├, ◄ ►, и чем чёрт не шутит — даже негритёнок! ☻
Ну это таки не ASCII.
У меня лично нет проблем разрешить тут что-то из юникода, но это уже достаточно фундаментальное решение.
И скобок (вообще парных символов) в юникоде таки, увы, мало.
У меня уже была шальная идея сделать в юникод пропозал на побольше скобок. Только надо до чёрта времени и разобраться, как это делается...
B> В том смысле, что дженерик имени вовсе не обязательно быть В СКОБКАХ, достаточно какого-нть префикса (типа @).
А как будешь записывать при 2 и больше параметрах? Map@MyKey@MyValue, или как?
B> Да и проблема <> больше надумана. Ну кто будет сравнивать классы "больше — меньше"??? Для грамматики < > — вообще не помеха, не стоило с этим вообще заморачиваться. Вон, C# — прекрасно работает и в ус не дует.
Не "прекрасно". foo(A<2,3>(X+Y)) уже принципиально неоднозначно. Для интерпретации применена эмпирика, описана в доках. Хорошая эмпирика, спасает в, наверно, 99.9% случаев. Но не 100.
(про socket stream разберу отдельно, позже)
The God is real, unless declared integer.
Re[5]: Почему dlang не обрел большой популярности?
Здравствуйте, netch80, Вы писали:
N>Не "прекрасно". foo(A<2,3>(X+Y)) уже принципиально неоднозначно.
Убедил! Значит ТЕМ БОЛЕЕ надо уделить внимание скобкам — почему не ┤├, ◄ ► ? Да, не АСКИ, но кому какое дело, если всё равно они есть в шрифтах?
Я просто к тому, что лучше даже <[ и ]>, чем белиберда из стандартных скобок! Тут Уолтер явно пролажал.
Даже если парсер легко съест круглые скобки, их плохо съест сам человек! Наглядность превыше всего.
Re[6]: Почему dlang не обрел большой популярности?
Здравствуйте, Baiker, Вы писали:
N>>Не "прекрасно". foo(A<2,3>(X+Y)) уже принципиально неоднозначно.
B>Убедил! Значит ТЕМ БОЛЕЕ надо уделить внимание скобкам — почему не ┤├, ◄ ► ? Да, не АСКИ, но кому какое дело, если всё равно они есть в шрифтах?
Дело есть в том, что это будет означать введение специальных "программистских" раскладок клавиатуры, и сопутствующих изменений чуть менее чем везде вокруг.
Ну и это должны быть таки скобки, а не уголки...
B>Я просто к тому, что лучше даже <[ и ]>, чем белиберда из стандартных скобок! Тут Уолтер явно пролажал. B>Даже если парсер легко съест круглые скобки, их плохо съест сам человек! Наглядность превыше всего.
Ну вот я лично для себя посравнивал на нескольких примерах и подумал, что меня круглые скобки вполне устраивают, даже если это приводит к выражениям типа complex(double)(1, -2) или List(Integer)(reserve:10).
Как проверить адекватность для большинства? Опрос тут точно не сработает: слишком много привыкших к <> несмотря на все их проблемы.
PS: ⌈⌉ ⌊⌋ — они конечно математика, но хоть какие-то есть...
Здравствуйте, netch80, Вы писали:
B>>Убедил! Значит ТЕМ БОЛЕЕ надо уделить внимание скобкам — почему не ┤├, ◄ ► ? Да, не АСКИ, но кому какое дело, если всё равно они есть в шрифтах?
N>Дело есть в том, что это будет означать введение специальных "программистских" раскладок клавиатуры, и сопутствующих изменений чуть менее чем везде вокруг.
Невелика проблема! Вон, во времена vi ВООБЩЕ СТРЕЛОК НЕ БЫЛО! Ничё, выкрутились через hjkl. Но прогресс-то идёт! Уже и ИЕРОГЛИФЫ в юникод засунули, сколько можно дрочить на ASCII??? Надо — есть AutoHotKey, он тебе любые "уголки" вставит! Тем более, что программисты всегда были продвинутые — не им плакаться, что "не могу ввести символ".
Что сейчас вообще работает на ASCII? Кругом юникод во все поля!
N>Ну вот я лично для себя посравнивал на нескольких примерах и подумал, что меня круглые скобки вполне устраивают, даже если это приводит к выражениям типа complex(double)(1, -2) или List(Integer)(reserve:10).
Нет, второго ЛИСПа нам не надо! "привыкнуть" — это ты можешь одного чела из 1000 убедить, но "нормально пользоваться" — увы, большинство так не будет. Либо "уголки", либо юникод. В конце концов, для ОЧЕНЬ сомнительных случаев, всегда можно объявить alias, чтобы не писать десятки уголков в одном выражении.
N>Как проверить адекватность для большинства?
Адекватность — она сама собой очевидна. Если код "пахнет", значит там уже что-то не в порядке.
Re[6]: Почему dlang не обрел большой популярности?
Здравствуйте, Baiker, Вы писали:
B>Значит ТЕМ БОЛЕЕ надо уделить внимание скобкам — почему не ┤├, ◄ ► ?
◄ ► совершенно не годится. У них "вес" куда как больше чем у среднего символа, неряшливыми черными пятнами в тексте будут выглядеть отвлекая внимание
Псевдографика тоже так себе символы, по другим причинам, но к ним хотя бы привыкнуть можно, если забыть про технические проблемы — неудобство ввода и не факт, что наличие во всех шрифтах,
Re[21]: Почему dlang не обрел большой популярности?
Здравствуйте, so5team, Вы писали:
S>Еще хуже объяснять умудренному опытом (но не гибкостью мышления и способностью смирится с тем, что его мнение нифига не единственно правильное) ветерану с 25-летним опытом, что префикс m_ многими воспринимается как такое же говно, как и суффикс _.
Идём в твой профиль, там по ссылкам и приходим в итоге на гитхаб в код sobjectizer
И что же мы там видим?
Префикс m_ просто повсюду.
А воплей то твоих было — ух!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[22]: Почему dlang не обрел большой популярности?
Здравствуйте, CreatorCray, Вы писали:
S>>Еще хуже объяснять умудренному опытом (но не гибкостью мышления и способностью смирится с тем, что его мнение нифига не единственно правильное) ветерану с 25-летним опытом, что префикс m_ многими воспринимается как такое же говно, как и суффикс _.
CC>Идём в твой профиль, там по ссылкам и приходим в итоге на гитхаб в код sobjectizer CC>И что же мы там видим? CC>Префикс m_ просто повсюду. CC>А воплей то твоих было — ух!
Дошло до того, что адекватный чел выложил undeaD — те самые удалённые модули! Ну как так можно похабно вести себя с библиотеками?! 
В том смысле, что дженерик имени вовсе не обязательно быть В СКОБКАХ, достаточно какого-нть префикса (типа @). Да и проблема <> больше надумана. Ну кто будет сравнивать классы "больше — меньше"??? Для грамматики < > — вообще не помеха, не стоило с этим вообще заморачиваться. Вон, C# — прекрасно работает и в ус не дует.
