>>Как раз вы в этом самом плену и находитесь. Вы настолько погрязли
>>в плену стериотипов ООП, что проецируете их на остальные парадигмы.
>
>Если кто-то и погряз в плену стереотипов ООП, то по крайней мере
>в структурном программировании такие люди обычно разбираются. А вот погрязшие в
>стереотипах структурного программирования обычно ООП осилить бывают не в состоянии. И
>понимают все "формально" - для них "class" - это особого вида
>"struct", а если нет "class", то сказать "метод" в их понимании
>- это преступление.
>Ага, ага...
Я говорю про значение термина "метод", а не про наличие синтаксических контрукций class или struct.
>>Я же просто точен. Чего и вам желаю. Все-таки техническая документация -
>>не художественная литература и требует формализации.
>
>Вот именно, что вы мыслите не "точно", а именно "формально". Формализация нужна
>транслятору, а хороший программист должен мыслить творчески, дешевые кодеры - не
>в счет. И художественная литература программистам тоже никак не мешает.
А потом получаются "художники", тонко чувствующие творческие люди, которые, отбросив формальности, пишут что-то вроде:
for(int i=1;i<5;i++)
{
cout << "OK? (y/n) ";
cin >> c;
// bol'shie i malen'kie bukvi
if(c!='y' && c!='Y' && c!='n' && c!='N') i--;
else i=10;
}
Вместо скучного и формального:
do
{
printf("OK? (y/n) ");
scanf("%c", &c);
c = toupper(c);
} while ((c != 'Y') && (c != 'N'));
Толку от творчества, ради творчества?.. Как скажется на качестве кода то, что "творческий" и "точный" программист стал функцию, структурного языка, ООП-шным термином "метод" называть?
