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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

Ivan

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

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

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


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


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



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


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

  • <<<... | 3731—3722 | 3721—3712 | 3711—3702 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 82


    № 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 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3711« (Владимир Лось)
    Кстати, а откуда взялся термин "кошачий пастух"?

    http://www.books.ru/shop/books/309225


    № 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)
    ___________________________
    Если Вы работаете с готовой библиотекой классов, то у Вас УЖЕ скомпонован глобальный контекст, в котором Вы УЖЕ можете работать со всеми включенными типами, и разумеется видимости УЖЕ на месте.
    Вы же не будете утверждать, что предпочли бы для каждого проекта начинать разработку с проектирования процессора?


    А об этом речи никто и не вёл.

    Было проиллюстрировано понятие контекста исполнения "по умолчанию" в рамках ООП-подхода, если вам угодно...


    <<<... | 3731—3722 | 3721—3712 | 3711—3702 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 82




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

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

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

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

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