Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  15:37[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4146—4137 | 4136—4127 | 4126—4117 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 213


№ 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)
___________________________

Мне хотелось проиллюстрировать мысль о том, что разных модулей может быть очень много, а интерфейс всего один. Я совсем не собирался разбирать все множество интерфейсов мировых железных дорог :)

Почему же один?
Вот мы уже как минимум два интерфейса наблюдаем: "вагончик--вагончик" и "вагончик--рельсы". :)
Кроме того, выгончики больше "смахивают" на объекты, чем на модули...
 AVC


№ 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)
___________________________
А можно подробнее?
Мне вот кажется, это хорошо, что вагончик подцепляется к вагончику, а не... ездит по нему. :)

Что подробнее?.. Я не понял Вашего вопроса.


Я не понял, почему различие интерфейсов "вагончик--вагончик" и "вагончик--рельсы" является "багой". :)
Возможно, Вы имели в виду что-то другое, поэтому я и прошу Вас высказать эту мысль подробнее.
 AVC


№ 4128   18-04-2007 06:52 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4115« (Руслан Богатырев)
___________________________
>>> Берем сущность в кредит. Мы потихоньку пришли в пещеры доисторической эпохи с вывеской "независимая компиляция".
Все бы Вам ярлыки навешивать :)
Я бы сформулировал по другому.
Я то пытаюсь исходить из принципа отчуждаемости.
Каждый модуль в Обероне является клиентом и сервером, со своим списком предоставляемых и запрашиваемых услуг. Кому он будет предоставлять эти услуги и кто будет предоставлять услуги ему в конкретной ситуации на конкретном компьютере разработчик модуля знать не может. Отсюда и все вопросы по поводу межмодульных взаимоотношений вообще и квалифицированного импорта в частности.





№ 4127   18-04-2007 06:45 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4124« (Руслан Богатырев)
___________________________
>> Вы слышите не то, что Вам говорят, а то, что искажено Вашим восприятием...

Держите себя в руках. Поменьше амбиций и побольше уважения к оппоненту
В чем проявилось мое неуважение к оппоненту?..


<<<... | 4146—4137 | 4136—4127 | 4126—4117 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 213


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования