Ассоциативный контейнер в оберонах

[Madzi]

Максимум, что можно сделать, это через метаинформацию типа выудить тип первого добавленного элемента и требовать ассертом, чтобы все остальные элементы ему соответствовали. Так как Вирт не дал нам дженериков

[DIzer]

Максимум, что можно сделать, это через метаинформацию типа выудить тип первого добавленного элемента и требовать ассертом, чтобы все остальные элементы ему соответствовали. Так как Вирт не дал нам дженериков

Почему - требуйте с пользователя обязательную реализацию метода

Код: [Выделить]

PROCEDURE CheckType (obj :ListItem):BOOLEAN;
BEGIN RETURN  Obj is Longint END CheckType; (при добавлении проверяйте этой функцией фактический тип данных).

[DIzer]

или я не прав 

[vlad]

Все наследуется от базового Object, у которого есть перегружаемый QueryInterface. Допустим у наc есть объект Object -> Drawable и его надо положить в контейнер, который хочет Object -> Hashable:

Наверно тяжелый день... не врубаюсь в смысл употребляемого слова - наследование (вроде в СИ его нет), разумеется эту ситуацию можно смоделировать низкоуровневыми
средствами( других нет    ) - вы это имеете ввиду?

Речь шла об обероне. Там наследование есть (немножественное). И о том как можно эмулировать множественное.

[DIzer]

Это не  моделирование множественного наследования - это использование промежуточного контейнера- обертки  но теперь я  не врубаюсь - причем здесь СИ?

[Madzi]

Использование контейнера обёртки, и есть эмуляция множественного наследования.
Допустим, что у нас есть объекты

Код: [Выделить]

TYPE
    Sortable = OBJECT ... END Sortable;
    Serialable = OBJECT ... END Serialable;
    Listenable = OBJECT ... END Listenable;
и есть базовый объект (MyObject), который хотелось бы унаследовать от данных. Прямого множественного  наследования  в оберонах нет, поэтому нужно эмулировать:

Код: [Выделить]

TYPE
    ProxySortable = OBJECT(Sortable)
        VAR
            myObject : MyObject;
        PROCEDURE AsMyObject() : MyObject;
        ...
    END ProxySortable;

    ProxySerializable = OBJECT(Serializable)
        VAR
            myObject : MyObject;
        PROCEDURE AsMyObject() : MyObject;
        ...
    END ProxySerializable;

    ProxyListenable = OBJECT(Listenable)
        VAR
            myObject : MyObject;
        PROCEDURE AsMyObject() : MyObject;
        ...
    END ProxyListenable

    MyComplexObject = OBJECT(MyObject)
        VAR
           sortable : ProxySortable;
           serializable : ProxySerialiable;
           listenable : ProxyListenable;
           ...
        PROCEDURE AsSortable() : ProxySortable;
        ...
        PROCEDURE AsSerializable() : ProxySerializable;
        ...
        PROCEDURE AsListenable() : ProxyListanable;
        ....
    END MyComplexObject;
Таким образом всё во всё преобразуется (наследуется), в прокси классах реализуется требуемое поведение.
Ну и главное потом не забыть разрушить циклические ссылки, для чего можно написать деструктор

Код: [Выделить]

PROCEDURE Done*();
BEGIN
    proxySortable^.myObject := NIL;
    proxySortable := NIL;
    proxySerializable^.myObject := NIL;
    proxySerializable := NIL;
    proxyListenable^.myObject := NIL;
    proxyListenable := NIL
END Done;


[DIzer]

2Madzi Наследуется - это не преобразуется. Не вижу смысла  в использовании термина "множественное наследование" в контексте топика и вашего примера(и заодно того о чем говопил Vlad, но в его случае дополнительно непонятно -= причем СИ) -только сбивает "с понталыку".

[vlad]

2Madzi Наследуется - это не преобразуется. Не вижу смысла  в использовании термина "множественное наследование" в контексте топика и вашего примера(и заодно того о чем говопил Vlad, но в его случае дополнительно непонятно -= причем СИ) -только сбивает "с понталыку".

Си при том, что на нем сделан COM (откуда название QueryInterface я и взял), в котором есть множественное наследование интерфейсов. Причем ручной работы для того, чтобы это все работало, там столько же сколько и в классическом обероне

[DIzer]

2Madzi Наследуется - это не преобразуется. Не вижу смысла  в использовании термина "множественное наследование" в контексте топика и вашего примера(и заодно того о чем говопил Vlad, но в его случае дополнительно непонятно -= причем СИ) -только сбивает "с понталыку".

Си при том, что на нем сделан COM (откуда название QueryInterface я и взял), в котором есть множественное наследование интерфейсов. Причем ручной работы для того, чтобы это все работало, там столько же сколько и в классическом обероне

И что?... предлагаете ради этой фигни лезть в реализацию COM...есть более приятные способы маяться дурью... мы обсуждаем хранилище -(говнохранилище)  с заданной структурой способное хранить  обьекты (какашки)  различных типов (т.е. различных размеров, цвета, консистенции).. Можно построить либо говнохранилище допускающее хранение 1. самих какашек , либо 2.  какашек в обертке - вы про какое хранилище говорите?

[ilovb]

   

[vlad]

предлагаете ради этой фигни лезть в реализацию COM...есть более приятные способы маяться дурью...

В реализацию COM никто лезть не предлагал. Базовая идея COM (множественное наследование) вполне понятна и не нова. Реализация этой идеи на языке без поддержки ООП (Си) тоже довольно проста и чего-то нового для оберона придумать не получится Использование этой идеи в языке без непосредственной поддержки - крайне неудобна (собственно поэтому все боятся COM При этом программисты на VB - COM не боятся и могут даже не знать что это такое - потому что язык заточен под COM.

мы обсуждаем хранилище -(говнохранилище)  с заданной структурой способное хранить  обьекты (какашки)  различных типов (т.е. различных размеров, цвета, консистенции).. Можно построить либо говнохранилище допускающее хранение 1. самих какашек , либо 2.  какашек в обертке - вы про какое хранилище говорите?

Применительно к оберону и универсальному хранилищу речь может идти только об обертках. Как раз в силу отсутствия множественного наследования в языке. Для создания оберток множественное наследование не нужно. Просто если бы множественное наследование было - то обертки не понадобились бы.

[DIzer]

В реализацию COM никто лезть не предлагал. Базовая идея COM (множественное наследование) вполне понятна и не нова. Реализация этой идеи на языке без поддержки ООП (Си) тоже довольно проста и чего-то нового для оберона придумать не получится Использование этой идеи в языке без непосредственной поддержки - крайне неудобна (собственно поэтому все боятся COM При этом программисты на VB - COM не боятся и могут даже не знать что это такое - потому что язык заточен под COM.

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

Применительно к оберону и универсальному хранилищу речь может идти только об обертках. Как раз в силу отсутствия множественного наследования в языке. Для создания оберток множественное наследование не нужно. Просто если бы множественное наследование было - то обертки не понадобились бы.я

  Да нет,  "не  в  силу отсутствия множественного наследования в языке"  - а в силу того, что определенные типы данных (INTEGER,REAL) -выпадают из ерархии (я говорю про КП ,  в случае остальных Оебронов приходится идти в любом случае на извращение (оборачивать все какашки, либо высерать их по определенной схеме (кроме высерающихся не по правилам) ) тут никакое множественное наследование не поможет.
Да, а насчет COM - бояться не правильное слово, повторяюсь -не фиг дурью маяться -для большую часть того что он дает, реализуют наитивные библиотеки и возможности ЯП, а разбираться  не имея мотивации - just for fun не для всех (по такой же причине не популярен Хаскель), и пример Байсека эту точку зрения весьма хорошо иллюстрирует.

[DIzer]

По этому Хаскилеры и называют свое евангелие  Learn You a Haskell for Great Good! - не специфицируя "добро" которое может получить читатель... а если будут специфицировать, то никто это дело даже и не откроет... 

[valexey]

По этому Хаскилеры и называют свое евангелие  Learn You a Haskell for Great Good! - не специфицируя "добро" которое может получить читатель... а если будут специфицировать, то никто это дело даже и не откроет... 

Это не евангелие :-) Книга не занимает около центрального положения среди всей литературы по хаскеллю.

[DIzer]

По этому Хаскилеры и называют свое евангелие  Learn You a Haskell for Great Good! - не специфицируя "добро" которое может получить читатель... а если будут специфицировать, то никто это дело даже и не откроет... 

Это не евангелие :-) Книга не занимает около центрального положения среди всей литературы по хаскеллю.

   Это метафора  используемая  мной как обозначение "откровений", передающих сущность топика неофитам.