alexs писал(а):видим нижнее использование перменной - а какой у неё тип?
согласно твоей логике - мне надо перелопатить кучу кода - вникнуть в него чтобы найти первое вхождеие перменной и её объявление
удобство твоего метода только для первого написания кода - для сопровождения этого кода - это абсолютно неприемлемо
Неправильная постановка вопроса.
Правильная: а какой ДОЛЖЕН быть у нее тип?
Если компилятор ругается на ошибку с типами, то он выведет тип ошибочной переменной и место, где она определена.
Если тебе надо, чтобы переменная была определенного типа, но тебя ломает искать место, где она определена - вставь явное требование типа выражения:
write (i:Integer)
И если i вдруг окажется не Integer - то будет ошибка компиляции, далее см. выше.
Наконец, в хорошей IDE после успешной компиляции тип переменной можно подсвечивать при наведении на нее мышкой.
alexs писал(а):Сейчас в паскале- я просто смотрю в секцию описания - (она всегда находится в одном месте)
Не забудь еще посмотреть во все вышестоящие секции, а также во все интерфейсы подключенных модулей. Одно место -
идеальный случай программы без процедур и библиотек.
Далее - совеременная теория и практика программирования рекомендуют определять переменные максимально близко к месту их использования, совмещать описание с инициализацией, иметь для них минимально необходимую область видимости.
Паскалевская секция переменных с область видимости в целую подпрограмму и без инициализации - каменный век.
В той же Аде, например, счетчик цикла определяется и инициализируется в самом операторе цикла и не виден за его пределами. В Паскале же надо еще в секцию переменных вписывать.
alexs писал(а):т.е. ты предлагаеш ввести особенности языков типа php И т.п. на которых пишутся мелкие заплатки - по принципу 1 раз написал, выполнил и выбросил. Для этого оно может и подходит
но если занимаешся серьёзными проектами и их сопровождением - к качеству исходников применяются совершенно другие требования.
PHP - бестиповой язык с многочисленными неявными преобразованиями данных в рантайме. Все глюки с типами там вылезают во время исполнения, в том числе через полгода после релиза.
Я предлагаю строгую статическую типизацию - все глюки с типами неминуемо приводят к ошибке компиляции.
Так что не надо необоснованных наездов. PHP терпеть не могу.
alexs писал(а):насчёт строк UTF8 или UTF16/32 - я ратую за быстродействие операций с этими объектами
в строке utf8 без полного разбора строки ты не можеш сказать где кончается символ и начинается другой
ты не можеш сдалть операцию s[1], s[32] и т.д.
для этого нужны вызовы функций с разбиением на символы
в случае UTF16/32 эти операции - это простое обращение процессора к определённому участку памяти - 1 маш. команда
разница в скорости просто громадная
Ты невнимательно меня читал. Для обработки
строк в памяти предлагалось строго 2 байта на символ. Для
файлов с текстами программ - UTF8.
alexs писал(а):ещё раз повторюсь - зачем изобретать все эти лишние знаки операций и дополнительные правила - можно просто один раз объявить тип переменной при её описании - это проще и понятнее.
Какие лишние знаки операций? Не понял.
"Проще и понятнее" пообъявлять типы десятка вспомогательных переменных, а потом потребовалась смена типа исходных - и давай менять все ручками. Ситуаций когда по логике вычислений переменный A должен быть такой же тип как у переменной Б полным-полно. Но в Паскале программист все равно должен сначала посмотреть тип Б, а потом приписать его А. Мартышкин труд получается - программист делает лишнюю работу.
Зачем для КАЖДОЙ переменной объявлять тип, если в абсоюлютном большинстве случаев с этим спокойно справится компилятор? По такой логике можно к каждому оператору ассемблерные вставки делать, дабы увеличить эффективность трансляции. А то неизвестно, в какие инструкции переведется тот или иной оператор?