Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4136 18-04-2007 07:31 | |
Ответ на »сообщение 4133« (AVC)
___________________________
Ответ на »сообщение 4131« (ASU)
___________________________
Мне хотелось проиллюстрировать мысль о том, что разных модулей может быть очень много, а интерфейс всего один. Я совсем не собирался разбирать все множество интерфейсов мировых железных дорог :)
Почему же один?
Вот мы уже как минимум два интерфейса наблюдаем: "вагончик--вагончик" и "вагончик--рельсы". :)
Кроме того, выгончики больше "смахивают" на объекты, чем на модули...
Если я правильно понял ASU, интерфейс "вагончик--вагончик" относится к вагончикам и даёт состав, а "вагончик--рельсы" относится уже к составу (ну и его вырожденному случаю - одному вагночику) :-)
№ 4135 18-04-2007 07:28 | |
Ответ на »сообщение 4128« (Сергей Перовский)
___________________________
Каждый модуль в Обероне является клиентом и сервером, со своим списком предоставляемых и запрашиваемых услуг. Кому он будет предоставлять эти услуги и кто будет предоставлять услуги ему в конкретной ситуации на конкретном компьютере разработчик модуля знать не может. Отсюда и все вопросы по поводу межмодульных взаимоотношений вообще и квалифицированного импорта в частности.
Если я правильно Вас понимаю -- Вы за то, чтобы компилятор не откладывал в долгий ящик разрешение внешних имен. Тогда ему надо знать, что они обозначают. Он это может выяснить и сам (по контексту использования). Например, понять, где переменная, а где процедура. Но константу от переменной уже не отличит. Значит, ему нужен "путевой лист", раз ленивый программист помогать ему не хочет. Компилятор должен знать, что надо куда-то залезть и извлечь эту важную для контроля информацию. Если программист хоть минимально ему помогает (называет "зоны поиска", "пространства имен", "капсулы идентификаторов"), то компилятор с задачей справляется. В противном случае он должен лезть в некое безвоздушное пространство, управляемое конфигуратором инструментальной среды и оттуда выковыривать. А что же програаммист? А он пребывает в святом неведении. Автопилот, понимаешь...
Значит, хотя бы имена этих зон (а не просто имен сущностей) надо указывать. Это и есть импорт. Если дальше не хотим явно префиксировать (квалифицировать) импортированную сущность точным именем модуля ("обратным адресом"), то получаем неквалифицирующий импорт. Если квалифицируем -- квалифицирующий. В такой постановке неквалифицирующий от квалифицирующего отличается двумя вещами:
1) компилятор сам всю квалификацию расставил за программиста (втихую или вгромкую, покумекав над коллизиями);
2) среда отключила показ квалификации.
Как из неквалифицирующего импорта получить квалифицирующий (если язык допускает оба)? Нажимаем заветную кнопочку -- компилятор лезет в "путевые листы" и сам прописывает квалификацию. Программист внимательно смотрит -- не ошибся ли ненароком этот автопилот? Если нет -- можно отключать, чтоб не мозолило глаза. Как нетрудно догадаться, тоже самое можно сделать в языке, у которое есть только квалифицирующий импорт. Программист нажимает ту же заветную кнопочку -- и, о чудо, все чужие сущности, как по мановению волшебной палочки, заполучили себе префиксы-квалификаторы. Теперь нажимает другую кнопочку -- имен не видать (но компилятор уже не должен ни о чем думать -- конкретизация наступила).
А что же Оберон? А он как был языком с квалифицирующим импортом, так и остался. Программист тоже весь из себя такой довольный. Развалился в кресле и предается благостному безделию. На этом и сказке конец. А кто слушал -- молодец.
№ 4134 18-04-2007 07:27 | |
Ответ на »сообщение 4132« (ASU)
___________________________
Еще раз... Система имеет свою собственную логику. Реализация этой логики происходит через посредство «слабых» связей. Нет «слабых» связей – нет логики; нет логики – нет системы... просто пазлы...
"Слабые" связи элементарным образом реализуются в program классического Паскаля через Call с текстовыми строками. По Вашему определению это становится системой вне зависимости от масштаба, функционала, архитектуры. Компилятор языка, насчитывающий 1 млн. строк, у которого нет "слабых связей" (они ему за ненадобностью), у которого все конкретизировано -- это не система. У меня вопросов здесь уже больше нет. Все понятно.
№ 4133 18-04-2007 07:22 | |
Ответ на »сообщение 4131« (ASU)
___________________________
Мне хотелось проиллюстрировать мысль о том, что разных модулей может быть очень много, а интерфейс всего один. Я совсем не собирался разбирать все множество интерфейсов мировых железных дорог :)
Почему же один?
Вот мы уже как минимум два интерфейса наблюдаем: "вагончик--вагончик" и "вагончик--рельсы". :)
Кроме того, выгончики больше "смахивают" на объекты, чем на модули...
№ 4132 18-04-2007 07:15 | |
Ответ на »сообщение 4130« (Руслан Богатырев)
___________________________
Есть три "блока":
* Scanner
* Parser
* CodeGenerator
Общаются друг с другом через посредников (через интерфейсы и даже через промежуточные "буферизующие" модули. Убираем границы модули. Сливаем все в один модуль. Осуществляем конкретизацию "имя сущности (интерфейс) --> сущность" (за компилятор, за линкер, за кого другого). Была система -- стала не-система?
совершенно верно.
Более общая формулировка: есть набор программного текста (1 млн. строк) на некоем языке программирования, реализующий задачу построения системы. Но при этом связи конкретизированы: нет отложенного "связывания", т.е. разбиения связки "имя сущности --> сущность". Все жестко. Намертво. Это система или нет? И почему?
Еще раз... Система имеет свою собственную логику. Реализация этой логики происходит через посредство «слабых» связей. Нет «слабых» связей – нет логики; нет логики – нет системы... просто пазлы...
№ 4131 18-04-2007 07:12 | |
Ответ на »сообщение 4129« (AVC)
___________________________
Я не понял, почему различие интерфейсов "вагончик--вагончик" и "вагончик--рельсы" является "багой". :)
Возможно, Вы имели в виду что-то другое, поэтому я и прошу Вас высказать эту мысль подробнее.
Мне хотелось проиллюстрировать мысль о том, что разных модулей может быть очень много, а интерфейс всего один. Я совсем не собирался разбирать все множество интерфейсов мировых железных дорог :)
№ 4130 18-04-2007 07:03 | |
Ответ на »сообщение 4097« (ASU)
___________________________
Первая имеет шанс стать системой, если появятся «слабые» связи... Если же Ваши модули прямо общаются друг с другом, то получите практически тот же монолит, что и во втором случае.
Есть три "блока":
* Scanner
* Parser
* CodeGenerator
Общаются друг с другом через посредников (через интерфейсы и даже через промежуточные "буферизующие" модули. Убираем границы модули. Сливаем все в один модуль. Осуществляем конкретизацию "имя сущности (интерфейс) --> сущность" (за компилятор, за линкер, за кого другого). Была система -- стала не-система?
Более общая формулировка: есть набор программного текста (1 млн. строк) на некоем языке программирования, реализующий задачу построения системы. Но при этом связи конкретизированы: нет отложенного "связывания", т.е. разбиения связки "имя сущности --> сущность". Все жестко. Намертво. Это система или нет? И почему?
№ 4129 18-04-2007 07:02 | |
Ответ на »сообщение 4126« (ASU)
___________________________
Ответ на »сообщение 4123« (AVC)
___________________________
А можно подробнее?
Мне вот кажется, это хорошо, что вагончик подцепляется к вагончику, а не... ездит по нему. :)
Что подробнее?.. Я не понял Вашего вопроса.
Я не понял, почему различие интерфейсов "вагончик--вагончик" и "вагончик--рельсы" является "багой". :)
Возможно, Вы имели в виду что-то другое, поэтому я и прошу Вас высказать эту мысль подробнее.
№ 4128 18-04-2007 06:52 | |
Ответ на »сообщение 4115« (Руслан Богатырев)
___________________________
>>> Берем сущность в кредит. Мы потихоньку пришли в пещеры доисторической эпохи с вывеской "независимая компиляция".
Все бы Вам ярлыки навешивать :)
Я бы сформулировал по другому.
Я то пытаюсь исходить из принципа отчуждаемости.
Каждый модуль в Обероне является клиентом и сервером, со своим списком предоставляемых и запрашиваемых услуг. Кому он будет предоставлять эти услуги и кто будет предоставлять услуги ему в конкретной ситуации на конкретном компьютере разработчик модуля знать не может. Отсюда и все вопросы по поводу межмодульных взаимоотношений вообще и квалифицированного импорта в частности.
№ 4127 18-04-2007 06:45 | |
Ответ на »сообщение 4124« (Руслан Богатырев)
___________________________
>> Вы слышите не то, что Вам говорят, а то, что искажено Вашим восприятием...
Держите себя в руках. Поменьше амбиций и побольше уважения к оппоненту
В чем проявилось мое неуважение к оппоненту?..
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|