объявленные в секции интерфейса, в секции реализации не повторяют.
Настало время ответить на отложенный вопрос: зачем прятать часть модуля, почему бы не выставить все напоказ? На это есть две причины, и обе веские.
Первая причина такова. Большие программы собирают из десятков библиотечных модулей, их создают разные люди, каждый из которых выбирает названия для своих объектов на свой вкус, не советуясь с другими. Если все эти имена сделать видимыми за пределами модуля, то некоторые из них совпадут и учинят невероятную путаницу.
Компилятор ищет идентификаторы сначала в текущем файле, а если их там нет, то в модулях из списка импорта USES. Причем перебирает модули в том порядке, в котором они перечислены. Есть вероятность, что вместо переменной, объявленной в одном модуле, компилятор наткнется на процедуру или функцию с тем же именем в другом модуле. Это может быть воспринято как ошибка и программа не скомпилируется.
Но хуже, если программа скомпилируется! В этом состоит вторая причина сокрытия лишних имен. Если компилятор найдет искомое, но не в том модуле, в котором вы предполагали – то-то будет морока с отладкой!
Отсюда вывод: не выставляйте напоказ ничего лишнего, будьте скромнее, – так поступают профессионалы. И все же полностью исключить нежелательное совпадение имен удается не всегда. Как быть? Выход есть – используйте префикс с именем модуля. Префикс – это приставка перед идентификатором, отделяемая от него точкой. Например, в главной программе нашего проекта вызовы процедур можно записать так:
MyLibr.Push(S);
while MyLibr.Pop(S) do...
Этим мы подсказали компилятору, что процедуры Push и Pop берутся из модуля MyLibr и боле ниоткуда.
Модуль, указанный в префиксе, должен упоминаться в списке USES. Но есть одно исключение – это модуль по имени SYSTEM. В этом библиотечном модуле собраны процедуры и функции, встроенные в Паскаль. Модуль SYSTEM в списке USES никогда не упоминают.
Иногда программисты называют свои процедуры и функции так же, как встроенные в модуль SYSTEM, – это не запрещено. И тогда для уточнения имен пользуются префиксами с именами библиотек, например:
System.Writeln(F); { стандартная процедура }
MyModule.Writeln(S); { моя «самоделка» }
Завершая обзор структуры модуля, обратим внимание на необязательные списки импорта USES в секциях интерфейса и реализации (рис. 148). Через эти списки библиотечный модуль импортирует нужные ему элементы из других модулей. Составляя списки, следуйте простому правилу: если внешний модуль требуется только в секции реализации, упоминайте его в списке USES секции реализации, а иначе – в секции интерфейса. Упоминать модуль в обоих списках нельзя. А когда импортировать нечего, список импорта не вставляют.
Оглядев структуру модуля, войдем теперь в сборочный цех IDE и рассмотрим порядок соединения модулей в единую программу – исполняемый файл.
Перед сборкой проекта все входящие в него библиотечные модули компилируются, в результате получаются файлы, расширения которых зависит от используемого компилятора. Так, для Borland Pascal файлы получат расширение TPU (это сокращение от «Turbo Pascal Unit»). Для Free Pascal это будут пары файлов с расширениями O и PPU. Модули можно компилировать как по отдельности, так и вместе со всем проектом. Рассмотрим оба случая.
Для компиляции отдельного модуля откройте его в редакторе и нажмите сочетание Alt+F9, или выберите пункт меню Compile –> Compile. Компилятор выполнит свою обычную работу по проверке ошибок и, при отсутствии таковых, сформирует библиотечный файл. На экране появится сообщение об успешной компиляции (рис. 150).
