На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
№ 3721 13-12-2005 06:35 | |
Ответ на »сообщение 3719« (al_mt)
___________________________
Скажите, вам понятно, что в ООП исполнение кода ведется в рамках контекста иерархии классов? Что делегируются действия (обработка сообщений)? Что глядя в конкретное место исходного текста нельзя сразу понять, что же делается, пока не выявишь взаимосвязь между классами и привнесенное в ОО-слои доопределение/переопределение функций обработки?
Я так понял, что здесь собственно осуждается эта самая "рамка контекста", т.е. "скрытность" ООП кода.
Я что не так понял??
Или Вы отрицаете саму идею контекста?
1. Неучтиво отвечать вопросом на вопросы.
2. Прочитайте внимательно все сообщения с самого начала дискуссии (начинайте прямо от Дейкстры).
3. Я формулировал тезис о том, что ООП обладает дополнительными "степенями свободы" по отношению к модульному программированию -- наследованием и полиморфизмом. Эта дополнительная гибкость при прочих равных условиях является дополнительным источником ошибок.
4. Локализация эффекта воздействия изменений в ОО-системе сложнее, чем в МП-системе (МП -- модульное программирование), из-за врожденного в у ООП делегирования функций обработки сообщений (пресловутого ОО-контекста). Это приводит к потере контроля над системой (ее сложностью).
5. ООП -- парадигма, доказавшая свою полезность и практичность, но я против ее диктатуры.
№ 3720 13-12-2005 06:35 | |
Ответ на »сообщение 3717« (Руслан Богатырев)
___________________________
Цитата:
Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).
Ну... Я бы сказал, что раздельная компиляция не обязательна, а в остальном согласен.
И как следствие не вижу ни малейшего противоречия между модульным и ОО программированием.
№ 3719 13-12-2005 06:21 | |
Руслан сказал:
Скажите, вам понятно, что в ООП исполнение кода ведется в рамках контекста иерархии классов? Что делегируются действия (обработка сообщений)? Что глядя в конкретное место исходного текста нельзя сразу понять, что же делается, пока не выявишь взаимосвязь между классами и привнесенное в ОО-слои доопределение/переопределение функций обработки?
Я так понял, что здесь собственно осуждается эта самая "рамка контекста", т.е. "скрытность" ООП кода.
Я что не так понял??
Или Вы отрицаете саму идею контекста?
Если Владимир данных взглядов не разделяет, а наоборот, извини :) значит это только к Руслану относится.
№ 3718 13-12-2005 05:45 | |
№ 3717 13-12-2005 05:29 | |
Ответ на »сообщение 3713« (al_mt)
___________________________
Прозвучало разделяемое Владимиром и Русланом утверждение, что "ООП скрывает часть кода от разработчика и это плохо"
Хороший индикатор дискуссии. Такая игра называется "нанайские мальчики". Объяснить или понятно?
Мои слова "инкапсуляция + наследование + полиморфизм" остались далеко за кадром. То, что любой модуль обеспечивает сокрытие информации за счет инкапсуляции (ради этого и задумывался), -- мимо ушей.
Прости, о чем мы говорим? Вы правда не понимаете или делаете вид?
Если не затруднит, ответьте на два вопроса:
1. Что такое модуль (в вашем понимании)?
2. С какими языками модульного программирования (не поддерживающими ООП) вы работали?
Вопросы несложные.
№ 3716 13-12-2005 05:22 | |
Ответ на »сообщение 3705« (al_mt)
___________________________
y:=sin(x);
Ву компре?
Вы имели в виду вызов стандартной функции sin, передачу ей в качестве аргумента переменной x и присваивание результат переменной y?
Давайте возьмем это в качестве примера для анализа той ситуации, которую я предлагал.
Рассмотрим два языка модульного программирования: Modula-2 и Оберон (в контексте нашего форума).
В Modula-2 мои действия будут следующими (варианты "обхода" могут быть разными):
1. Посмотреть DEFINITION-модуль и выяснить, является ли sin экспортируемой процедурой-функцией. Если да, смотрим в IMPLEMENTATION на реализацию функции (это нам интересно на предмет возможного оказания воздействия на другие модули системы при ее изменении).
2. Посмотреть список неквалифицирующего импорта (FROM ... IMPORT) в начале IMPLEMENTATION-модуля. Если нашли, смотрим, из какого модуля импортируется, его DEFINITION, где указано, что она делает (а вдруг не вычисляет синус, а делает что-то другое).
3. Если поиск по пунктам 1 и 2 закончился неудачей, значит, функция sin реализована в IMPLEMENTATION данного модуля и при этом не экспортируется. Находим реализацию этой функции. Видим, что она делает.
В Обероне мои действия будут следующими:
1. Функция sin не является встроенной функцией языка и не может при такой записи импортироваться, тогда была бы запись вида y := Math.sin(x) с явным указанием имени модуля (неквалифицирующего импорта в Обероне нет). Значит, эта функция sin реализована только внутри данного модуля. Ищем реализацию функции в данном модуле. Видим, что она делает.
2. Чтобы оценить эффект воздействия при возможном изменении смотрим, есть ли у имени процедуры-функции при ее реализации признак импорта (звездочка). Если есть, значит экспортируется (и где-то снаружи используется).
Все очень просто.
№ 3715 13-12-2005 05:17 | |
Прозвучало разделяемое Владимиром и Русланом утверждение, что "ООП скрывает часть кода от разработчика и это плохо"
Нет, ну мне это нравится!
Тут наверное яростнее сторонника ПОЛНОГО СОКРЫТИЯ исходного кода от клиентов компонентов, чем я не найти и вдруг появляется al_mt и на белом глазу вываливает прямо противоположное утверждение!
Для вас повторяю, что по моим взглядам, компоненты должны быть полностью бинарными (ну, может быть в байт-коде, обероновских слимах, инферновских dis-ах...) и предоставлять наружу только строго оговоренный интерфейс (каким уже способом - вотрой вопрос).
№ 3714 13-12-2005 05:12 | |
Ответ на »сообщение 3713« (al_mt)
___________________________
Прозвучало разделяемое Владимиром и Русланом утверждение, что "ООП скрывает часть кода от разработчика и это плохо"
ГДЕ ЭТО У МЕНЯ БЫЛО ?????!!!!!
Или вы сами с сиобой дискуссию ведёте? :о)
№ 3713 13-12-2005 05:08 | |
ОК. Положите булыжники с иероглифами на место - не будем разорять могилки, вернёмся к конкретике:
Прозвучало разделяемое Владимиром и Русланом утверждение, что "ООП скрывает часть кода от разработчика и это плохо"
Было такое утверждение? Все согласны и готовы поддержать?
p.s. Только просьба, если кто-то желает развернуть мысль, то играем в "50 слов".
№ 3712 13-12-2005 04:55 | |
Ответ на »сообщение 3709« (al_mt)
___________________________
Если Вы работаете с готовой библиотекой классов, то у Вас УЖЕ скомпонован глобальный контекст, в котором Вы УЖЕ можете работать со всеми включенными типами, и разумеется видимости УЖЕ на месте.
Вы же не будете утверждать, что предпочли бы для каждого проекта начинать разработку с проектирования процессора?
А об этом речи никто и не вёл.
Было проиллюстрировано понятие контекста исполнения "по умолчанию" в рамках ООП-подхода, если вам угодно...
Отслеживать это обсуждение
Дополнительная навигация: |
|