На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
№ 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. От чего долго-долго уходили и к чему впоследствии вернулись - к сишному разброду и шатанию в исходниках.
№ 3839 15-12-2005 17:09 | |
Ответ на »сообщение 3820« (Сергей Перовский)
___________________________
Допустим Вы обнаружили в каком-то библиотечном модуле ошибку. Исправили и перезагрузили -- и все дела. И часть программ стала работать не правильно. Потому, что с их точки зрения это была "не ошибка, а особенность". Вот отсюда и возникает ад dll.
Сколько раз отлаженные программы не желали работать при переносе на другую машину, где была установлена другая версия (ИСПРАВЛЕННАЯ :o)) какой нибудь dll.
Сергей, тенденция такова, что в конечном счете Вам придется поставлять программы вместе со своей персональной версией Windows. :)
Что касается программирования в соответствии не с интерфейсом, а "фичами" (а скорее - "багами"), то при таком подходе ошибки будут всегда - и при динамической, и при статической линковке.
Я вижу единственное спасение - "контрактное программирование" охаянного здесь Мейера (не все же у него плохо!). Нарушение "контракта" наказывается сразу и публично.
Вот тогда ошибки при использовании чужих компонентов исчезнут. Ну, почти. :)
Пожалуйста, дайте мне компоновщик, только тогда я буду уверен, что никто в мою программу не внесет "исправления".
Что касается именно компоновщика, то это все есть, далеко ходить не надо.
Например, XDS и не даст Вам другого варианта кроме статической линковки.
BlackBox позволяет упаковать Ваш релиз целиком в один exe-файл. Чем не аналог статического линковщика?
Конечно, с точки зрения ресурсов, помодульная загрузка экономичнее. Но что будет с надежностью?
Причина ненадежности не в динамической загрузке как таковой, а в программировании в соответствии с "фичами", что, в свою очередь, вызвано ошибками в "стандартных" компонентах и несоразмерной сложностью их использования (сравнить хотя бы OLE/COM с взаимодействием модулей в Обероне!).
Я согласен, что вопрос непростой.
Надо думать.
№ 3838 15-12-2005 16:37 | |
Ответ на »сообщение 3831« (Takun)
___________________________
Так еще лучше.
Разве что я не заметил каких-нибудь подводных камней.
В конце концов, адреса импортируемых подпрограмм определяются только на этапе загрузки. Почему и с константами не поступить сходным образом?
№ 3837 15-12-2005 14:24 | |
Ответ на »сообщение 3835« (Сергей Губанов)
___________________________
Ответ на »сообщение 3823« (Руслан Богатырев)
...(timestamp/checksum, причем внутри каждого модуля эту пару для каждого импортируемого им модуля)...
Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.
Из серии "в огороде бузина, а Киеве -- дядька".
Я про timestamp/checksum всего модуля -- мне в ответ про fingerprint сущностей.
Простите, о чем мы толкуем? Я про свое предложение (что делалось во многих реализациях Modula-2), где фиксируется модуль в целом (фиксируя дату компиляции!, это понятно?), а вы про другой подход. Почитайте повнимательнее, разберитесь.
№ 3836 15-12-2005 14:20 | |
Ответ на »сообщение 3835« (Сергей Губанов)
___________________________
Не модуль снабжается фингерпринтом, а каждая экспортируемая модулем сущность! Каждая экспортируемая константа, каждая экспортируемая переменая, процедура и тип - у каждой экспортируемой сущности свой фингерпринт.
Не много ли оверхеда, например, на байтовую константу?
№ 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, да и много зачем ещё могли бы понадобиться "внутренние модули". "Внутренние модули" необязательно должны быть видны клиентам, это - просто очередной уровень абстракции, помогающий структурировать информацию для человека-разработчика.
№ 3833 15-12-2005 12:37 | |
Ответ на »сообщение 3832« (Сергей Перовский)
___________________________
Мы пришли к тому, от чего пытаемся уходить: на компьютере придется хранить (и одновременно загружать) несколько версий одного модуля, и со своей программой передавать все необходимые модули (а вдруг у клиента не та версия).
Интересно, оданко получается.
1. Соответствие модулей фиксируется только интерфейсом. Динамическое связывание. Динамическая подгрузка/выгрузка. Вам не подходит.
2. Статическая сборка всех модулей. Вам не подходит.
3. Компромиссный вариант: часть собирается статически (точнее, статически устанавливаются зависимости от версий), а другая - динамически, причем есть возможность управлять: статические переводить в динамические и наоборот. Вам не подходит.
Предложите четвертый вариант.
№ 3832 15-12-2005 11:59 | |
Ответ на »сообщение 3823« (Руслан Богатырев)
___________________________
Мне хотелось бы покрасить
Бакенбарды в цвет зеленый,
В руки веер взять побольше,
Чтобы их никто не видел (с)
>>А далее иметь специальный конфигуратор, который позволял бы снимать/ослаблять контроль на предмет подмены модулей на лету.
Мы пришли к тому, от чего пытаемся уходить: на компьютере придется хранить (и одновременно загружать) несколько версий одного модуля, и со своей программой передавать все необходимые модули (а вдруг у клиента не та версия).
Для надежности все разработчики будут указывать точные версии используемых сторонних модулей и экономия будет только в случае если у загруженных программ случайно совпала версия используемого модуля.
И за это мы должны заплатить созданием интелектуального компоновщика-загрузчика?
Мне кажется, что это очень напоминает тот путь, который уже прошел майкрософт, создав по сути компонентную, расширяемую операционную систему.
Они нахлебались проблем и теперь ищут альтернативу. NET, по сути, попытка сбежать с этого корабля.
Отслеживать это обсуждение
Дополнительная навигация: |
|