Редактирование: Языки программирования, 16 лекция (от 26 октября)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

Языки программирования 26.10.06
 

В прошлый раз мы остановились на
межмодульных связях.
 

Библиотечный модуль Модулы дыва состоит
из двух подмодулей, связанных одним именем.:
<OL>
	<LI>Модуль-интерфейс, гнде только
	определения
	<LI>Модуль-реализация. Реализация и
	дополн объявления для неё, а так же инициализирующая часть.
</OL>
Дельфи:
физически представляет собой один
модуль, но присутствует понятие ирнтерфейся и реализации, разница
чисто синтаксическая. Есть более тонкие моменты, которые отличают,
они связаны с механизмом межмодульных связей[http://medobsor.ru]. 

 

Не разрешаются вложенные моудли.
 

Возникают два понятия: потенциальная и
непоср видимость.
 

Непосредственна &ndash; конгда имя
можно употреблять без уточнЯюзей информации
Протенцияалдьная &ndash; с уточняющей,
указание имени модуля через точку. Везде через точку, только С++
выпендрился, там ::
 

Непосредственно ыидимыми являются
только имена модулей. Все остальные имена потенциально видимые только
те, что в разделе определений. Имена из модулей-определений видимы
потенциально. Из модуля определений осуществляется экспорт в
глобальное пространство имён.
 

Все имена равноправны. 

 

Кроме понятие экспорта, есть понятие
импорта. Импорт может быть как в модуль определений, так и вмоудль
реализации. Таблицпа имён из модуля реализаций &ndash; конкатенация
таблицы из модуля поерделений.
 

Модуль реализации только импортироет,
как из модуля определений (всегда, неявно), так и из других модулей.
 

Есть две формы импорта:
IMPORT список модулей.
Стандартные и пользовательские модули
абсолютно равноправны, при этом реальный ждоступ получаем тогда,
когда делуем предожение IMPORT. Оно должно быьб первым среди всех
объявлений. С точки зрения реализации компилятор должен просмотреть
все папки поиска, и подкачать соотв таблицы имён. При этом соотв
имена в этом модуле, если в нём есть предложение IMPORT, все имена из
него ст ановятся видимы потенциально. Приходиться писать
InOut.WriteLn. Программистов это раздражает, поэтому есть другая
формаи импорта: FROM имя модуля IMPORT список идентификаторов &ndash;
и имена становятся видимы непосредственно. Это сделано в дань
программистом, которые ленятся набивать длинные имена. Беда непоср
импорта в конфликте имён. Причём могут конфликтовать как с именами
других модулей, так и с локальными. Локальные имеют больший приоритет
(граждане первого сорта имеют больше прав, относительно иммигрантов).
Это достаточно удобная модель.
 

Отличия Дельфи:
Имена из модульной реализации
недоступны никому, но есть едиственная форма предложения импорта:
uses список модулей &ndash; импорт непосредственный. Если имена
конфликтуют между собой, то в этом случае непоср видимост снимается. 

 

С первой точки зрения этот подход более
улдобен, но когда лектор столкнулся с программированием в Дельфи и
Модуле-2, то на Модуле-2 текст читать приятнее. Ибо когда в uses
полтора десятка модулей, то дрогадаться, из какого модуля
идентификатор, трудно. Поэтому Борланд всегда поставлял ос всеми
своими компиляторами grep. А в Модуле-2 мы обречены на успех при
поиске по файлу.
 

Порядок загрузки модулей поерделяется
порядком зависимостей. В момент загрузки доступна инициализация &ndash;
begin ... end. .
 

В этих языках есть принцип &ndash;
РОРИ, Разделение
<OL>
	<LI>Определения
	<LI>Реализация
	<LI>Использования
</OL>
Главенствовал в ЯП в 70-ч годах, когда
появились ЯП с чёткой модульной структурой.
 

Есть ли в Си разделение определния и
реализации? Это можно сделать, но ручками. И есть много подводных
камней. Например, каждый хедер начинается с ifndef, дабы избежать
повторного включения модулей. 

#ifndef SYMBOL
#define SYMBOL
...
#endif
 

Интересно с этрой точки зрения
посмотреть на язык Оберон, что же он упростил. История идёт по
спирали, и там от РОРИ с первого взгляда отказалисб.
В первой версии языка:
DEFINITION M
опр-я
ENDM.
 

MODULE M
ENDM.
Модно выкинукть понятия модуля
определения как такового. Вместо этого можно просто помечать. То же,
что и в ассемблере.
MODULE M;
	TYPE T* - если после имени стоит
звёздочка, то оно экспортируемое
	REOCRD
	END;
 

	PROCEDURE P* (X:T);
	END;
ENDM.
 

На первый взгляд это отступление от
РОРИ. Ибо программисту использующему нужен только интерфейс. На самом
деле, в к концу 80-началу 90х годов получил распространение приём,
что язык пишется как часть системы программирования. 

 

//На 3 этаже стояли перфораторы
 

Прграммистдимеет делло с программой,
которую просматривает в режиме онлайн.
 

С этой точки зрения интересен Eifel,
который генерировал документирующие модули. 

 

В современных ЯП (Си шарп, Джава)
интерфейс и реализация не разделяются. На этот шаг пошли потому, что
там есть программы, коотрые генерируют документацию по исходным
кодам.
 

Наследование кода &ndash; Контрол-Ц &ndash;
Контрол-В [:]||||||||||||[:]
 

Программисты не любят писать
документацию, но теперь есть средства, которые генерируют её
автоматически по комментариям.
 

В Обероне от Модулы осталось поняте
Модуля, исчезли списки определений, но появились списки экспорта, и
оставили только один способ импорта &ndash; IMPORT. Также отсутствует
понятие главной проргаммы. Считается, что пользователь погружён в ОС,
и модули экспортируют туда себя. Операционная среда Оберон
предоставляет шелл, и пользователь может запускать комманды &ndash;
экспортированные функции.
 

После педедыва язык Ада.
//педедыв
Стиль Си: использование префиксов. Что
делать если имена конфликтуют имена &ndash; сплошной геморрой.
Минимум, который необходим &ndash; структуризация модулей, хотя бы
один уровень.
 

Язык Ада представдяет собой
ультимативную модель.
Есть Пакет &ndash; модуль (не путать с
джавой)
Пакет состоит из
<OL>
	<LI>Спецификации пакета
	<LI>Тело пакета
</OL>
package M is
объявления
end M;
package body M is
 

end M;
Функцию pop на аде написать нельзя,
потому что у адской функции не должно быть побочного эффекта.
 

В Аде есть механизм импорта, но он
только для раздельной трансляции.
 

Импорта как такового нет.
Есть пакет STANDART. 

Прространства имён могут вкладываться &ndash;
коренное отличие от других ЯП.
Спецификация пакетов &ndash; неявный
список экспорта. Доступны они только потенциально. 

Имена пакетов должны быть уникальными.
Явной конструкции импорта нет, ибо в
других ЯП они нужны для раздельной трансляции. 

Синтаксис: P1.P2. ... .PN
Интересный вопрос: нужна вложенность
или нет.
В Аде есть такая штука, как перегрузка
имён и функций, что есть в совр ЯП. Но в Аде можно было также
перкрывать стандартные процедуры и функции, а акже знаки стандартных
операций. Беда в том, что стандартные операции не префиксные
(нектоторые неизвестно какие, например a[i]). Если бы вопрос был
только о префиксных, то вопрос потенциальной видимости не мешает. 

Пусть есть
package Vectors is
	type Vector is
 

	function &laquo;+&raquo;(x,y:Vector)
return Vector;
end Vectors;
 

X, Y,Z:Vectors.Vector;
 

X:=Y+z &ndash; нельзя
vectors.&laquo;+&raquo;(y,z) &ndash;
смысл?
 

//программисты, скрипя сердцем...
[:]|||||||||||||||[:]\
 

Если попытаться на си написать
A=B*exp(-i*C)*F(x), где всё комплексное, то математик скажет, что это
не язык. Поэтому Страуструп добавил возможность добавления новых
операторов.
 

И возникает вопрос, зачем тогда
переопределение операторов если нет непоср области видимости? Поэтому
в Аду есть uses список пакетов. Тогда можно для векторов писать
Z:=X+Y. На первый взгляд всё замечательно. Но что делать, если
возникате конфликт имён? Если X оперделён глобально, в M1, M2. И это
приводит к программам, смысл которых от uses меняектся.
 

Проектирование систем:
top-down
bottom-up
Системы разбиваются на набор модулей,
вопрос в том, с каком порядке разбивать.
<OL>
	<LI>Сверху вниз: разбить систему на
	модули, эти модули на ещё модули и т. д. Проблема в том, что делают
	заглушки. И тут мы тренируемся на лягушатнике, а когда бросают в
	бассейн &ndash; буль-буль
	<LI>Снизу вверх. Модули нижнего уровня
	отлаживаются проще. Недостаток: заказчик не знает, что хочет, и
	меняет заказ, и видит готовую систему в самый последний момент.
</OL>

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%2C_16_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_26_%D0%BE%D0%BA%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29

Редактирование: Языки программирования, 16 лекция (от 26 октября)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 18: / Строка 18: @@
 модуль, но присутствует понятие ирнтерфейся и реализации, разница
 чисто синтаксическая. Есть более тонкие моменты, которые отличают,
-они связаны с механизмом межмодульных связей.
+они связаны с механизмом межмодульных связей[http://medobsor.ru].
 </P>
 <P STYLE="margin-bottom: 0cm"><BR>