Евгений Темиргалеев писал(а):
Интересно, на что завязано умолчальное понимание этого недоразжёванного куска? Нигде не говорится, что CAP будет делать с не-буквами. Как показала практика, уже несколько человек ожидают игнорирование...
А как же принцип "не навреди"? Если символ находится вне компетенции функции, то должен быть либо трап, либо ничего. Тем более, если в документации ничего не сказано, то и делать ничего не должна, а если она делает или хотя бы иногда может сделать что-то неожиданное, то должно быть большое предупреждение: портит данные, фигню не передавать!
Вот дана вам функция, и сказано, что она строчные символы преобразует в прописные. Вы ей даёте цифру, что ждёте в ответ? Неужели undefined behaviour? Или, может быть, какую-то заглавную букву ожидаете? В данном описании дана не область определения, и не область значений функции, а дано утверждение вида "если, то": Если (на входе строчная буква), то (на выходе соответствующая прописная буква). Таким образом, ожидается, что функция активизируется, т.е. выполняет работу по
преобразованию символа, только в случае передачи ей строчного символа. В остальных случаях ожидается, что преобразования выполнено не будет.
Если мне сказано, что функция преобразует строчные символы в прописные, я ожидаю, что при выполнении её в цикле над строкой, содержащей предложение на английском языке, она изменит только буквы, а, например, знаки препинания, оставит нетронутыми.
Это всё, я считаю, от чрезмерной краткости документации. (Должно быть, но) не указано явно, что задана именно область определения функции, а не условное поведение, как ожидается при чтении. Возможно, другими читателями (математиками, например) ожидается иное. Я привык читать описания интерфейсов защищённых, т.е. соблюдающих принцип "не навреди".
Что касается конкретной реализации, то она меня вполне устраивает, если дополнительная проверка увеличила бы генерируемый код и создала неоптимальность. Так я имею возможность один раз проверить входные параметры на валидность, после чего в 10 местах вызывать CAP, не внося дополнительных проверок. Я считаю, что недостаток прежде всего в документации. Ну, и в тенденции рассматривать CAP как библиотечную функцию, а не как "особую компиляторную магию".
Приходится использовать такой вот обходной манёвр:
Код:
PROCEDURE Cap(ch: CHAR): CHAR;
BEGIN
CASE ch OF
| 'a'..'z': RETURN CAP(ch)
ELSE RETURN ch
END
END Cap;