Здравствуйте, igna, Вы писали:
I>В рассматриваемом случае и при использовании языка, позволяющего определять свои типы, не уступающие по эффективности встроенным, можно было бы просто определить типы degree и radian, и тогда можно было бы и булевый параметр убрать, и метод/функцию переименовывать не пришлось бы.
+1
I>Все в сослагательном наклонении, потому-что конкретная проблема надумана, аргумент конечно же должен задаваться в радианах.
Можете выбрать любой цвет, при условии что вы выбираете черный
Не все так однозначно.
Градусы хороши своей целочисленностью.
I>Возможно стоит добавить, что это преобразование нужно выполнять только при вводе информации от пользователя, внутри программа должна иметь дело только с радианами.
см. выше.
То же, кстати, относится к доброй половине финансовых программ, где цены, вроде как, не целые, но из лучше хранить как целые или как пару целых.
I>PS. Этот автор у тебя тоже в числе экспертов?
Я *там* в качестве эксперта упоминал Глассборо — есть сомнения, что он эксперт? Тот, кого ты *там* нашел, я впервые увидел. Ладно, здесь это офтопик в любом случае.
А эта конкретная статья в RSS прилетела, посмеялся, пока читал, решил сюда запостить.
Надеюсь, что вы тоже посмеялись.
С другой стороны, хоть и смешно, но проблема реальная: во многих признанных API (в винде, например) булевские переменные летают только в путь, в результате смотришь в вызов функции с пятью true, как дурак, и пытаешься понять, что же они все означают.
Так что мысль вроде как и очевидна, да, видать, лень побеждает — bool же проще сунуть, чем целое перечисление объявлять или вообще специальный полноценный тип ваять.
