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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

На базарной площади довольно часто можно слышать высказывания об Обероне. Мне кажется, что на базарной площади пора появиться ветке об этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы этой системы, что полезного можно извлечь из него для программирования на Дельфи (например) и др.

Ivan

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

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

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


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


Ссылки по теме "Оберон" и "Компонентный паскаль"



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


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Разработка препроцессора gpre для delphi\freepascal.
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • <<<... | 3851—3842 | 3841—3832 | 3831—3822 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 70


    № 3841   16-12-2005 01:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3831« (Takun)
    ___________________________
    Оно бы хорошо, но как быть с

    VAR A:ARRAY M.Len OF INTEGER;

    Запретить?


    № 3840   15-12-2005 19:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3839« (AVC)
    ___________________________

    Сергей, тенденция такова, что в конечном счете Вам придется поставлять программы вместе со своей персональной версией Windows. :)

    Что касается программирования в соответствии не с интерфейсом, а "фичами" (а скорее - "багами"), то при таком подходе ошибки будут всегда - и при динамической, и при статической линковке.

    Я вижу единственное спасение - "контрактное программирование" охаянного здесь Мейера (не все же у него плохо!). Нарушение "контракта" наказывается сразу и публично.
    Вот тогда ошибки при использовании чужих компонентов исчезнут. Ну, почти. :)
    <...>
    Причина ненадежности не в динамической загрузке как таковой, а в программировании в соответствии с "фичами", что, в свою очередь, вызвано ошибками в "стандартных" компонентах и несоразмерной сложностью их использования (сравнить хотя бы OLE/COM с взаимодействием модулей в Обероне!).
    Я согласен, что вопрос непростой.
    Надо думать.

    Посмотрите на зоопарк, который творится в мире программирования J2ME: каждый из вендоров аппаратно-программной платформы по-своему понимал новую и несовершенную спецификацию MIDP1.0 и клепал собственную реализацию, делая приправу из собственных нативных фич (доступ к файловой системе у Siemens, собственный "расширенный" GUI у Nokia и т.д.). Теперь этот зоопарк перерождается в другую фазу - на рынок вышли новые вендоры со своими фичами, а "старички" уходят на более внятную MIDP2.0. :p
    Что более удивительно так это то, что разработчики никоим образом не стремяться абстрагироваться от частностей реализации, а напрямую используют "грязный хак", специально затачивая разработки под КОНКРЕТНЫЕ мобилы. В итоге порождается куча кастомизационных вещей и дублирующего кода в виде ЦЕЛЕВОЙ КОМПИЛЯЦИИ под конкретные аппараты. (например, исходники мобильной аськи Jimm занимают 25МБ, тогда как рабочий модуль ~100КБ)
    Фсё. Круг замкнулся.

    Вот она - Java. От чего долго-долго уходили и к чему впоследствии вернулись - к сишному разброду и шатанию в исходниках.
     iZEN


    № 3839   15-12-2005 17:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3820« (Сергей Перовский)
    ___________________________


    Допустим Вы обнаружили в каком-то библиотечном модуле ошибку. Исправили и перезагрузили -- и все дела. И часть программ стала работать не правильно. Потому, что с их точки зрения это была "не ошибка, а особенность". Вот отсюда и возникает ад dll.
    Сколько раз отлаженные программы не желали работать при переносе на другую машину, где была установлена другая версия (ИСПРАВЛЕННАЯ :o)) какой нибудь dll.


    Сергей, тенденция такова, что в конечном счете Вам придется поставлять программы вместе со своей персональной версией Windows. :)

    Что касается программирования в соответствии не с интерфейсом, а "фичами" (а скорее - "багами"), то при таком подходе ошибки будут всегда - и при динамической, и при статической линковке.

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


    Пожалуйста, дайте мне компоновщик, только тогда я буду уверен, что никто в мою программу не внесет "исправления".


    Что касается именно компоновщика, то это все есть, далеко ходить не надо.
    Например, XDS и не даст Вам другого варианта кроме статической линковки.
    BlackBox позволяет упаковать Ваш релиз целиком в один exe-файл. Чем не аналог статического линковщика?


    Конечно, с точки зрения ресурсов, помодульная загрузка экономичнее. Но что будет с надежностью?  


    Причина ненадежности не в динамической загрузке как таковой, а в программировании в соответствии с "фичами", что, в свою очередь, вызвано ошибками в "стандартных" компонентах и несоразмерной сложностью их использования (сравнить хотя бы OLE/COM с взаимодействием модулей в Обероне!).
    Я согласен, что вопрос непростой.
    Надо думать.
     AVC


    № 3838   15-12-2005 16:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3831« (Takun)
    ___________________________

    Так еще лучше.
    Разве что я не заметил каких-нибудь подводных камней.
    В конце концов, адреса импортируемых подпрограмм определяются только на этапе загрузки. Почему и с константами не поступить сходным образом?
     AVC


    № 3837   15-12-2005 14:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3835« (Сергей Губанов)
    ___________________________

    Ответ на »сообщение 3823« (Руслан Богатырев)
    ...(timestamp/checksum, причем внутри каждого модуля эту пару для каждого импортируемого им модуля)...

    Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.


    Из серии "в огороде бузина, а Киеве -- дядька".

    Я про timestamp/checksum всего модуля -- мне в ответ про fingerprint сущностей.

    Простите, о чем мы толкуем? Я про свое предложение (что делалось во многих реализациях Modula-2), где фиксируется модуль в целом (фиксируя дату компиляции!, это понятно?), а вы про другой подход. Почитайте повнимательнее, разберитесь.


    № 3836   15-12-2005 14:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3835« (Сергей Губанов)
    ___________________________


    Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.

    Не много ли оверхеда, например, на байтовую константу?
     iZEN


    № 3835   15-12-2005 13:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3832« (Сергей Перовский)
    ...Мы пришли к тому, от чего пытаемся уходить...

    Мы бы пришли к этому если бы Руслан Богатырев был прав. Но он в данном случае заблуждается.

    Ответ на »сообщение 3823« (Руслан Богатырев)
    ...(timestamp/checksum, причем внутри каждого модуля эту пару для каждого импортируемого им модуля)...

    Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.


    № 3834   15-12-2005 13:22 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3793« (Руслан Богатырев)
    ___________________________


    <...>
    Так, теперь берем класс. Да что тут обсуждать – посмотрите на Java. Капсула есть, интерфейс есть, внутри все есть. А новый тип внутри есть? А модуль внутри есть?  А другой класс внутри есть? Озадачили, надо подумать. Ну, тогда, наверное, не все. Но ведь капсула и интерфейс, чего еще надо?

    В современной Java (Java2) возможно создание четырёх вложенных (nested) классов. Их виды:
    * класс-член (nonstatic member class)
    * статический класс (static member class)
    * анонимный класс (anonymous class)
    * локальный класс (local class)
    Каждый из них наделён определёнными правами доступа к другим членам (даже к закрытым) класса, в котором они определяются. В общем, это механизм, призванный как можно гибко решить проблему передачи ссылки this в случае объекта-владельца и Class.this в случае класса-владельца информации о типе (метакласс).
    Ну да не суть важно.

    Под модульностью в ООП я ставлю знак равенства между модулем и объектом. Но в случае, если у класса есть  статические члены, то и между понятием модуля и этим классом_со_статическими_членами.

    Класс_без_статических_членов не может представлять из себя модуль, в нём нет "капсулы", в которой инкапсулированы реальные данные. То же относится и к интерфейсам Java.

    Кстати, про интерфейсы Java (немного отвлечёмся). Очень занятно то, что объявленные в них константы напрямую линкуются в реализующие эти интерфейсы классы!!! Это начит, что при изменении интерфейса с константами нужно перекомпилировать все классы, которые его имплементируют, что никак нельзя назвать модульностью. Вообще-то хорошим тоном считается не определять в интерфейсах никаких констант для передачи их в реализующие классы; интерфейс служит для определения типов и ничего другого, хотя в исходниках многих промышленных продуктов на Java это правило нарушается, даже в самом JDK (см. java.io.ObjectStreamConstants).

    Ну ладно. Это всё детали. Главное - в Java возможны "внутренние модули".

    Хорошо, смотрим на модуль. Интерфейс есть? Еще бы, ведь его и делят на две части – интерфейсный модуль и исполнительный модуль. В Обероне эти части совмещают, но совмещают текстуально, а на самом деле (для компилятора и клиентов модуля) части разделены. Так, с интерфейсом у модуля более-менее понятно. Теперь капсула. Что в нее можно поместить? Так вроде все можно – переменные, константы, типы, процедуры, классы и модули. Что, и модули? Ну да. Хотя, не совсем. Модули можно было внутрь модуля поместить только в Modula-2. Назывались локальными модулями. Но толку от этого мало. Снаружи их все равно не видать. А зачем были нужны? Так управляли внутри модуля областями видимости – как капсулы для внутреннего, так сказать, употребления. В них тоже много чего можно было поместить. И зачем был такой наворот? Вот и Вирт подумал, зачем? Не используют, лишняя таможня. Вот поэтому и убрал из Modula-2 при переходе к Оберону. Значит, в Обероне их нет? Нет. Т.е. в Обероне модуль внутрь модуля поместить нельзя? Точно, нельзя. Ладно, и с этим разобрались.

    В Java возможны "внутренние модули" и они нужны в первую очередь чтобы не загромождать внешние связи передачами ссылок на объект-экземпляр класса и на сам класс. Так называемые классы-хелперы, помогающие клиентам работать с основным классом: Итераторы, Операции по обходу структуры объекта, Компараторы, Сериализаторы, Слушатели событий в технике JavaBeans, да и много зачем ещё могли бы понадобиться "внутренние модули". "Внутренние модули" необязательно должны быть видны клиентам, это - просто очередной уровень абстракции, помогающий структурировать информацию для человека-разработчика.
     iZEN


    № 3833   15-12-2005 12:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3832« (Сергей Перовский)
    ___________________________

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

    Интересно, оданко получается.

    1. Соответствие модулей фиксируется только интерфейсом. Динамическое связывание. Динамическая подгрузка/выгрузка. Вам не подходит.

    2. Статическая сборка всех модулей. Вам не подходит.

    3. Компромиссный вариант: часть собирается статически (точнее, статически устанавливаются зависимости от версий), а другая - динамически, причем есть возможность управлять: статические переводить в динамические и наоборот. Вам не подходит.

    Предложите четвертый вариант.


    № 3832   15-12-2005 11:59 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3823« (Руслан Богатырев)
    ___________________________
    Мне хотелось бы покрасить
    Бакенбарды в цвет зеленый,
    В руки веер взять побольше,
    Чтобы их никто не видел (с)

    >>А далее иметь специальный конфигуратор, который позволял бы снимать/ослаблять контроль на предмет подмены модулей на лету.
    Мы пришли к тому, от чего пытаемся уходить: на компьютере придется хранить (и одновременно загружать) несколько версий одного модуля, и со своей программой передавать все необходимые модули (а вдруг у клиента не та версия).
    Для надежности все разработчики будут указывать точные версии используемых сторонних модулей и экономия будет только в случае если у загруженных программ случайно совпала версия используемого модуля.
    И за это мы должны заплатить созданием интелектуального компоновщика-загрузчика?
    Мне кажется, что это очень напоминает тот путь, который уже прошел майкрософт, создав по сути компонентную, расширяемую операционную систему.
    Они нахлебались проблем и теперь ищут альтернативу. NET, по сути, попытка сбежать с этого корабля.


    <<<... | 3851—3842 | 3841—3832 | 3831—3822 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 70




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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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