Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
СГ>Основной принцип КОП (так как я его понимаю) гласит: модуль должен экспортировать только abstract class/interface/definition..., а также экспортировать фабрику по производству объектов реализующих указанные интерфейсы.
Ссылку, плиз, на описание основных концепций.
Ты взвдашь догмы своих любимых технологий (которые сильно недоразвиты) за концептуальные пробемы. В нормально спроектированных компонетных средах (коими являются дотнет и Ява) таких ограничений нет. Можно экспортировать классы и создавать наследников в других модулях. Абстрактные классы, к слову, тоже могут иметь методы содержащие реализацию.
СГ> Но сами по себе конкретные классы этих объектов-реализаторов модуль экспортировать не должен. Объясняется это тем, что модуль должен оставлять за собой право на изменение реализации в последующих версиях этого же самого модуля которые не приведут к тому чтобы пользователи этого модуля должны были бы перекомпилироваться при смене версии модуля (тоже самое должно быть справедливо при замене этого модуля на аналогичный модуль от другого производителя).
Чущь. Чтобы интерфейс не изменялся достаточно его не изменять. Если он изменился и наследники использовали исходное описание, то соврешенно нормально, что их прийдется поправить и пересобрать. Компонетность от этого не убавляется. Изменение же внутренней реализации к проблемам приводить не обязано.
СГ> КОП в том и состоит, что мы в любой момент можем из работающей системы изъять старый модуль и заменить его новым модулем (быть может от другого производителя) на лету без перезапуска системы и тем более без перекомпиляции (ибо у нас может просто не быть исходников).
Ну, про заменую на лету — это ты придумывашь. Если модуль используюется, то любая полноценная ОС не даст его удалить. Можно конечно грузить две версии параллельно, но это уже другое решение. Без перекомпиляции? Тут проблем нет.
СГ>P. S. СГ>В оригинальных оберонах, т.е. откуда КОП пошло,
Акстись. Компонетный подход никакого отношения к Оберонам не имеет. Этой концепции сто лет.
СГ> JIT компиляции не было — вот поэтому и был наложен запрет на межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
В КОМ тоже джит компиляции небыло. Но подобных ограничений тоже небыло. Некоторые языки исползующие КОМ позволяли наследоваться от КОМ-классов.
В общем, прекрати ставить знак равенства между Обероном и КОП. Это уже не смешно.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Leshi, Вы писали:
J>>Если ты еще не убился с отлаживанием — рекомендую от м.н. не отказываться, через короткое время сам все поймешь . L>Сколько же должно пройти времени? Я не первый день программирую на С++,
Уверенность приходит с опытом. Читай внимательней:
Если ты еще не убился с отлаживанием
L>почему-то желание отказаться от множественного наследования не возникало. Что я делаю не так?
Потратишь побольше времени — желание возникнет... , и станет навязчивой идеей .
Здравствуйте, Cyberax, Вы писали:
C>Копирование — это плохо.
Чем.
C> Вдобавок, мое решение более гибкое — я могу C>менять реализацию делегата в run-time. Да и вообще, по-моему, гораздо C>более простое решение.
Я тоеж. Обертки еще никто не запрещал. Вот только если они ставятся в пику типизированному подходу, то — это очень плохо.
Делегирование — это не всегда приемлемое решение. Так оно приводит ктому, что я не смогу требовать от класса некоего контракта, а буду надяеяться на то, что мне подсунут приемлемую реализацию. Ну, и это банально медленеее. Обертка требует перезакгузки рекистров, а копирование происходит во время коппиляции.
В общем, приемущество именно то что trait-ы работают во врмея компиляции исключая накладные расходы и ошибки времени выполнения.
Они не являются заменой делегированию. Но и делегирование не является заменой trait.
trait — это безопасный вариант множественного наследования. По сути идея trait-а заключается в том, что trait-ы не могут иметь не абстрактных переменных и следовательно конструкторов. Это позволят им подмешивать чистую реализацию и избавляет от таких проблем МН как брилиантовое наследование и неоднозначности. К тому же trait проще для понимания.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>while тоже нет. Есть конструкция проверки значения и конструкция перехода.
AVK>Которые от while отличаются исключительно внешним видом
Ну, да. Буквы в авфовите тоже отличаются исключительно внешим видом. Хотя странно слышать, что две конструкции могут вообе быт похожи на одну.
while — это паттерн структурной конструкции. Его реализация — это две не структурных команды сравнения и перехода. Пожожего тут ничего нет. Напомню, что переход ожет быть потнециально и за пределы блоков (да их по просту нет в низкоуровневых языках вроде мсил-а или ассемблера).
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А в ФЯ тебе копирование не нравится. Непоследовательно, однако А
копирование плохо тем, что просто происходит ненужное дублирование кода.
> Делегирование — это не всегда приемлемое решение. Так оно приводит > ктому, что я не смогу требовать от класса некоего контракта, а буду > надяеяться на то, что мне подсунут приемлемую реализацию.
А вот тут приходит на помощь слово final/sealed.
> Ну, и это банально медленеее. Обертка требует перезакгузки рекистров, > а копирование происходит во время коппиляции.
Как раз медленнее оно не будет — нормальный JIT способен будет
распознать код делегирующих методов и заоптимизировать их.
> trait — это безопасный вариант множественного наследования. По сути > идея trait-а заключается в том, что trait-ы не могут иметь не > абстрактных переменных и следовательно конструкторов. Это позволят им > подмешивать чистую реализацию и избавляет от таких проблем МН как > брилиантовое наследование и неоднозначности. К тому же trait проще для > понимания.
Так я и предлагаю, по сути, одну из реализаций автоматического
подмешивания реализации.
Cyberax пишет: > Так я и предлагаю, по сути, одну из реализаций автоматического > подмешивания реализации.
Кстати, я думаю никого не удивит, если я скажу что в VW ST именно такая
фишка и реализована.
При помощи аннотаций задаётся список селекторов метода которые будут
делегироватся и атрибут которому будут делегироваться вызовы. Точнее не
атрибут, а селектор метода результату которого будут делегироваться
вызовы. Всё происходит через #doesNotUnderstand: но ничего не мешает
нагенерить соответсвующих методов. Такая схема позволяет делегировать
разные сообщения различным получателям.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
А я и не говорил, что этого делать вот прямо совсем уж нельзя. Если отдавать себе отчет к чему это приводит, то это делать можно. Как известно, в Component Pascal можно экспортировать классы и создавать наследников в других модулях. Абстрактные классы, естественно, тоже могут иметь методы содержащие реализацию, более того — даже финальную реализацию, сверх более того (в отличие от Java и .NET) в Component Pascal абстрактные классы могут быть даже value-type (что в совокупности с value-type массивами позволяет писать программы вовсе никогда не использующие инструкции new — динамического распределения памяти)!!!!!!
СГ>> Но сами по себе конкретные классы этих объектов-реализаторов модуль экспортировать не должен. Объясняется это тем, что модуль должен оставлять за собой право на изменение реализации в последующих версиях этого же самого модуля которые не приведут к тому чтобы пользователи этого модуля должны были бы перекомпилироваться при смене версии модуля (тоже самое должно быть справедливо при замене этого модуля на аналогичный модуль от другого производителя).
VD>Чущь. Чтобы интерфейс не изменялся достаточно его не изменять. Если он изменился и наследники использовали исходное описание, то соврешенно нормально, что их прийдется поправить и пересобрать. Компонетность от этого не убавляется. Изменение же внутренней реализации к проблемам приводить не обязано.
А если модуль экспортирует только абстрактные классы/интерфейсы и фабрику по производству объектов реализующих эти интерфейсы, но ни за что на свете никогда не экспортирует реальные расширяемые классы, тогда никто не имеет возможности от них отнаследоваться, а значит абсолютно все лишены счастья когда либо в будущем перекомпилироваться при замене данного модуля другим содержащим немного другие расширяемые классы. Дело в том, что абстрактные классы/интерфейсы являются элементом самой архитектуры программы и поэтому (практически) никогда не изменяются, а реальные расширяемые классы как имплементаторы абстрактных, могут изменяться от версии к версии, и от производителя. КОП предполагает изготовление модулей на продажу, естественно, что продавать можно только указанные мной модули ибо только такие модули в любой момент можно заменить на аналогичные без перекомпиляции всей зависящей от них части системы.
СГ>> КОП в том и состоит, что мы в любой момент можем из работающей системы изъять старый модуль и заменить его новым модулем (быть может от другого производителя) на лету без перезапуска системы и тем более без перекомпиляции (ибо у нас может просто не быть исходников).
VD>Ну, про заменую на лету — это ты придумывашь. Если модуль используюется, то любая полноценная ОС не даст его удалить. Можно конечно грузить две версии параллельно, но это уже другое решение. Без перекомпиляции? Тут проблем нет.
Естественно, что все модули-клиенты предварительно тоже надо выгрузить (разобрать пирамиду импорта модулей)
СГ>>P. S. СГ>>В оригинальных оберонах, т.е. откуда КОП пошло,
VD>Акстись. Компонетный подход никакого отношения к Оберонам не имеет.
Ага, конечно! Еще скажите, что Клеменс Шиперски не является сооснователем Oberon Microsytems.
Здравствуйте, Joker6413, Вы писали:
L>>почему-то желание отказаться от множественного наследования не возникало. Что я делаю не так?
J>Потратишь побольше времени — желание возникнет... , и станет навязчивой идеей .
Я девять лет программирую и отлаживаю на С++. И ничего...
Не, разумеется, можно нагородить всякую фигню, используя любой инструмент.
Но знаете, надевать пробку на вилку только потому, что ею можно уколоться
Поэтому отказываться от МН там, где оно удобнее любых других решений — это нафиг.
Здравствуйте, Cyberax, Вы писали:
C>А копирование плохо тем, что просто происходит ненужное дублирование кода.
Видмо ты не понял. Если такой код уже есть, то или выдается ошибка, или происходит затирание. Весь смысл в том чтобы избежать дублирования.
>> Делегирование — это не всегда приемлемое решение. Так оно приводит >> ктому, что я не смогу требовать от класса некоего контракта, а буду >> надяеяться на то, что мне подсунут приемлемую реализацию.
C>А вот тут приходит на помощь слово final/sealed.
Не-а. Синклер тут рядом привел хороший пример нарушения контракта.
C>Как раз медленнее оно не будет — нормальный JIT способен будет C>распознать код делегирующих методов и заоптимизировать их.
Подумай. У тебя есть некий адрес объекта. По некоторому смещению в этом объекте лежит адрес объекта которому делегируется вызов. Как джит что-то сможет сделать? Он обязан будет взять ячейку с адресом получателя, скопировать ее в регист и вызвать метод. Далее ему нужно будет востановить исходный адрес чтобы продолжить работу.
А статическое делегирование и есть замена кода метода.
C>Так я и предлагаю, по сути, одну из реализаций автоматического C>подмешивания реализации.
Ты предлагаешь делегирование. Просто с упрощением синтаксиса. Этот паттерн известен давно и у него есть свои плюсы. Но есть и минусы. В качестве добавления реализации лучше подошли бы trait-ы, по-моему.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Т.е. основных концепций КОП зарадились "on 30-Dec-2004"? Во оно как.
Хотя о чем я. Никакого описания концепций по этой ссылке нет. Там куча ссылк. Ты приведи мне ссылку именно на определение основных концепций КОП.
VD>> В нормально спроектированных компонетных средах (коими являются дотнет и Ява) таких ограничений нет.
СГ>А я и не говорил, что этого делать вот прямо совсем уж нельзя. Если отдавать себе отчет к чему это приводит, то это делать можно.
Так значит можно? Ну, тогда нет вопросов. А отчет себе отдавать нужно всегда.
СГ>А если модуль экспортирует только абстрактные классы/интерфейсы и фабрику по производству объектов реализующих эти интерфейсы, но ни за что на свете никогда не экспортирует реальные расширяемые классы, тогда никто не имеет возможности от них отнаследоваться, а значит абсолютно все лишены счастья когда либо в будущем перекомпилироваться при замене данного модуля другим содержащим немного другие расширяемые классы.
Да? Ну, измени интерфейс такого абстрактного класса и вместе посмемся над тем как ты обойдешся без перекомпиляции и т.п.
В общем, запомни как отчий наш. Нормальная компонентная среда должна обеспечивать возможность обходиться без перекомпиляции если не изменилась используемая часть публичного интерфейса компонента. Все! Все остальное частности и домыслы.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет:
> C>А копирование плохо тем, что просто происходит ненужное дублирование > кода. > Видмо ты не понял. Если такой код уже есть, то или выдается ошибка, > или происходит затирание. Весь смысл в том чтобы избежать дублирования.
Я подмешиваю один трейт в два класса — у меня один и тот же код будет
продублирован два раза.
> C>Как раз медленнее оно не будет — нормальный JIT способен будет > C>распознать код делегирующих методов и заоптимизировать их. > Подумай. У тебя есть некий адрес объекта. По некоторому смещению в > этом объекте лежит адрес объекта которому делегируется вызов. Как джит > что-то сможет сделать? Он обязан будет взять ячейку с адресом > получателя, скопировать ее в регист и вызвать метод. Далее ему нужно > будет востановить исходный адрес чтобы продолжить работу.
_Нормальный_ JIT, то есть HotSpot строит ветки кода, в которых
происходит изменение поля с адресом делегата. На эти ветки ставится хук,
который вызывает изменение зашитого статического адреса перехода в
JIT-коде этих методов.
> C>Так я и предлагаю, по сути, одну из реализаций автоматического > C>подмешивания реализации. > Ты предлагаешь делегирование. Просто с упрощением синтаксиса. Этот > паттерн известен давно и у него есть свои плюсы. Но есть и минусы. В > качестве добавления реализации лучше подошли бы trait-ы, по-моему.
Само по себе _добавление_ не особо нужно, обычно нужно, чтобы
добавленный код реализовывал какой-нибудь интерфейс. Поэтому мой метод
вполне себе нормален.
Здравствуйте, VladD2, Вы писали:
VD>Т.е. основных концепций КОП зарадились "on 30-Dec-2004"? Во оно как.
Вообще-то, это "Last modified on 30-Dec-2004".
VD>Хотя о чем я. Никакого описания концепций по этой ссылке нет. Там куча ссылк. Ты приведи мне ссылку именно на определение основных концепций КОП.
Там есть ссылки на его книги. Надо их читать.
Впрочем, большая часть мудрости доступна непосредственно из хелпа к BlackBox.
Здравствуйте, VladD2, Вы писали:
VD>В общем, запомни как отчий наш. Нормальная компонентная среда должна обеспечивать возможность обходиться без перекомпиляции если не изменилась используемая часть публичного интерфейса компонента. Все! Все остальное частности и домыслы.
Это возможно только при отказе от натуральной компиляции модулей в нативный машинный код в пользу компиляции в некий промежуточный язык с последующей JIT компиляцией.
Сейчас специально проверил. В одном модуле определил класс объектов с приватной переменной типа 32-битового целого числа и методом печатающим это число в консоль. В другом модуле определил класс потомок от первого класса, создаю объект и вызываю у него метод печати. Изготовил еще один модуль аналогичный первому, но приватную переменную сделал 64-битной. Внешний интерфейс класса объектов, стало быть, не изменился.
Подменил первый модуль вторым: в .NET — работает, в BlackBox — не работает: "Link Call Failed object TestExt1.BaseType^ inconsistently imported from TestExt2". Разница между BlackBox и .NET в JIT компиляции в последней, в то время как BlackBox компилирует модули непосредственно в нативный машинный код.
Так что моя оговорка:
СГ>P. S. СГ>В оригинальных оберонах, т.е. откуда КОП пошло, JIT компиляции не было — вот поэтому и был наложен запрет на СГ>межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
Здравствуйте, Cyberax, Вы писали:
C>Я подмешиваю один трейт в два класса — у меня один и тот же код будет C>продублирован два раза.
Тебя не должно трогать где что делает компилятор. Возможно он и одним вариантом кода обойдется, а возможно сдублирует его если типы того требуют.
C>_Нормальный_ JIT, то есть HotSpot строит ветки кода, в которых C>происходит изменение поля с адресом делегата. На эти ветки ставится хук, C>который вызывает изменение зашитого статического адреса перехода в C>JIT-коде этих методов.
Агащазблин.
C>Само по себе _добавление_ не особо нужно, обычно нужно, чтобы C>добавленный код реализовывал какой-нибудь интерфейс. Поэтому мой метод C>вполне себе нормален.
Никуда не годен твой метод. Глюков бльше чем пользы. Да и при наличии trait-ов интерфейсы уже не так становятся актуальны. Их можно очно так же реализовывать.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Это возможно только при отказе от натуральной компиляции модулей в нативный машинный код в пользу компиляции в некий промежуточный язык с последующей JIT компиляцией.
Агащазблин. Дельфи и Васик так работали спокойно.
СГ> СГ>Сейчас специально проверил. В одном модуле определил класс объектов с приватной переменной типа 32-битового целого числа и методом печатающим это число в консоль. В другом модуле определил класс потомок от первого класса, создаю объект и вызываю у него метод печати. Изготовил еще один модуль аналогичный первому, но приватную переменную сделал 64-битной. Внешний интерфейс класса объектов, стало быть, не изменился.
СГ>Подменил первый модуль вторым: в .NET — работает, в BlackBox — не работает: "Link Call Failed object TestExt1.BaseType^ inconsistently imported from TestExt2". Разница между BlackBox и .NET в JIT компиляции в последней, в то время как BlackBox компилирует модули непосредственно в нативный машинный код.
СГ>Так что моя оговорка:
СГ>>P. S. СГ>>В оригинальных оберонах, т.е. откуда КОП пошло, JIT компиляции не было — вот поэтому и был наложен запрет на СГ>межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
СГ>оказалось не напрасной.
Дермом твой Блэкбокс является. Отсюда и проблемы. А все оговорки от незнания. Создай КОМ-объект на чем угодно и попробуй с ним. Пока публичный интерфейс будет низменен проблем не будет.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет:
> C>_Нормальный_ JIT, то есть HotSpot строит ветки кода, в которых > C>происходит изменение поля с адресом делегата. На эти ветки ставится > хук, > C>который вызывает изменение зашитого статического адреса перехода в > C>JIT-коде этих методов. > Агащазблин.
Не "агащазблин", а RTFM. HotSpot именно так и работает, причем еще он
точно так же инлайнит виртуальные вызовы. Могу показать место в
исходниках JDK, где об этом говорится.
> C>Само по себе _добавление_ не особо нужно, обычно нужно, чтобы > C>добавленный код реализовывал какой-нибудь интерфейс. Поэтому мой метод > C>вполне себе нормален. > Никуда не годен твой метод. Глюков бльше чем пользы. Да и при наличии > trait-ов интерфейсы уже не так становятся актуальны. Их можно очно так > же реализовывать.
Стоп. Интерфейсы НИКУДА не денутся, так как это средство абстракции.
Трейты могут помочь только в их реализации.
Здравствуйте, VladD2, Вы писали:
VD>Дермом твой Блэкбокс является. Отсюда и проблемы. А все оговорки от незнания. Создай КОМ-объект на чем угодно и попробуй с ним. Пока публичный интерфейс будет низменен проблем не будет.
Приехали. А я ведь именно об этом и говорю, перечитайте:
СГ>....А если модуль экспортирует только абстрактные классы/интерфейсы и фабрику по производству объектов реализующих эти интерфейсы, но ни за что на свете никогда не экспортирует реальные расширяемые классы,..........
COM объект — это и есть объект-реализатор интерфейса. То есть модель компонентных объектов (COM) в точности следует всем директивам компонентного программирования (COP). Экспорту, в COM, как раз подлежат только интерфейсы и фабрики. В COM нельзя экспортировать (расширяемый) класс объектов, можно лишь их фабрику, т.е. не класс, а сами объекты.
Здравствуйте, VladD2, Вы писали:
VD>Дермом твой Блэкбокс является. Отсюда и проблемы.
Кстати, не гоже так отзываться о продукте первоначально разработанного как кросплатформенная среда под виндос-95 и Макинтош (и которому в прошлом году, кстати, исполнилось 10 лет), но тем не менее он по скорости работы обгоняет современный .NET в несколько раз! Уже позабыли?
В данном конкретном тесте, .NET-товский сборщик мусора работал в 163/50 = 3.26 раза медленнее чем BlackBox-совский сборщик мусора. Если вспомнить про задачку с N^2 ссылками между N объектами, то там тоже .NET-товский сборщик мусора работал более чем в 3 раза медленнее чем BlackBox-совский сборщик мусора.
N кол.связей один объект вся структура BlackBox .NET Отношение времен .NET/BlackBox
2000 4 млн 8 Kb 16 Mb 0.23 сек 0.83 сек 3.60 раз
3000 9 млн 12 Kb 36 Mb 0.55 сек 2.27 сек 4.13 раз
4000 16 млн 16 Kb 64 Mb 1.17 сек 3.99 сек 3.41 раз
5000 25 млн 20 Kb 100 Mb 1.70 сек 6.37 сек 3.75 раз
6000 36 млн 24 Kb 144 Mb 2.67 сек 10.03 сек 3.76 раз
7000 49 млн 28 Kb 196 Mb 4.17 сек 18.12 сек 4.35 раз
8000 64 млн 32 Kb 256 Mb 4.12 сек 22.22 сек 5.39 раз
И что же это такое получается? Вот уже на двух совершенно разных задачах .NET-товский сборщик мусора работает более чем в 3 раза медленнее чем BlackBox-совский сборщик мусора. Как это объяснить? Может быть в следующей версии .NET сборщик мусора станет более шустрым?
.
Я не первый день программирую на С++, 
, и станет навязчивой идеей 
Перекуём баги на фичи!
