Здравствуйте, AlexCab, Вы писали:
AC>COM был (и есть) слишком сложен и "массивен". .NET сделали проще
Компонентная модель дотнета (и WinRT) существенно сложнее СОМ. Я уж не говорю о компонентной модели XAML, которая используется в WPF. СОМ на самом деле очень прост, но вот его использование в С++ весьма некомфортно, потому что язык под это неприспособлен. В рамках же дотнета СОМ весьма близок к родной компонентной модели.
AC>Что если сделать ещё более простую технологию?
Еще более простая технология будет нужна еще меньше СОМ.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали: VD>>>1. Компонент. AC>>Это почти то же что объект, он также имеет состояние и поведение. Основные отличия в интерфейсе: 1) интерфейсов может быть несколько AVK>В СОМ, дотнете, жабе интерфейсов тоже может быть несколько.
Наследование интерфейсов в Java это не тоже самое, что несколько отдельных интерфейсов(как в COM). AC>>; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом. AVK>В СОМ вызов QueryInterface,
Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: 1) как-то организовать получение GUID интерфейса конкретного компонента, 2) оба взаимодействующих компонента должны получить таблицы методов(QueryInterface), 3) оба компонента должны проверить наличие функций "connection", и если таковые есть, вызвать. И это только установка связи, и ещё кучу всего нужно будет реализовать для разрыва(обычного и аварийного) связи.
В КОП это делается парой операторов("connect", "disconnect"), остальное забота рантайма. AVK>в жабе и дотнете операция приведения типа.
Причём здесь приведение типа? Оно лишь, даёт возможность скрыть/показать часть полей объекта. Управление интерфейсами в КОП похоже на управление Qt'ишными слотами-сигналами. AC>>И небольшими отличиями в поведении: после выполнения конструктора, внутри компонента, в отдельном потоке, может быть запущена функция(или несколько), что делает компоненты активными(способными делать что то самостоятельно, не дожидаясь вызовов методов). AVK>Без проблем реализуется поверх СОМ, дотнета и джавы.
В КОП поддерживается "из коробки". AC>>Отличий действительно не много AVK>А точнее их просто нет.
Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса и поддержки рантайма, для этого будет нужна куча соглашений, которая превратится в кучу служебного кода, что есть дополнительный, не нужный геморрой для программистов. К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит. AVK>Автор видимо не в курсе того, что сам СОМ вообще почти ничего не говорит про внутреннюю реализацию (ну, с некоторой натяжкой, можно активацию СОМ-серверов к этому разве отнести). СОМ говорит только об интерфейсах и работе с ними, а за границей интерфейса может быть что угодно, в том числе и абсолютно необъектные функции.
Наверно автор писал о том как это делают обычно, а не о том какими, "нетрадиционными", способами это можно сделать в принципе. AVK>Так что картинка в корне неверная
Мопед не мой. AC>>Windows Runtime — API Metro-приложений, основанный на технологии COM, с заточкой под .NET. Я неправильно понял? AVK>http://en.wikipedia.org/wiki/WinRT#Services — пункты 2.1
Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом.
В КОП тоже есть метаданные, но в отличии от, нет необходимости тащить в пакет(в терминах Java) описание каждого метода и класса, достаточно набора сигнатур типов интерфейсов. Если тип(сигнатура) интерфейса сервера и клиента(в терминах COM, в КОП явного разделения нет) совпадает, значит типы методов(аргументов-результатов) и свойств так же совпадают. К тому же проверка сигнатуры выполняется только при подключении интерфейса, а не для каждого вызова метода. AVK>и 2.2.
.NET'овская система типов в COM? Аналогичное предыдущему. AC>>JavaBeans? Это просто набор правил кодирования. AVK>Нет, это стандарт, позволяющий стороннему коду анализировать метаданные бинов. JavaBeans, не нашёл про анализ метаданных AVK>В джаве это в виде соглашений просто потому что обычный джавовский класс уже отвечает практически всем признакам компонента.
А где это ещё используется кроме Java?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
AC>>>; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом. AVK>>В СОМ вызов QueryInterface, в жабе и дотнете операция приведения типа. VD>Вот здесь, возможно, он имеет в виду нечто большее чем просто проверка интерфейса. VD>Возможно, что тут подразумевается наличие чего-то вроде реактивности.
Нет, это не совсем про реактивность. VD>Если правильно понял подключение ему нужно для перехвата вызовов
Грубо говоря, для получения таблицы методов, как в COM'е, и... VD>и автоматического оповещения связанных компонентов.
... да, для "оповещения" связывающихся компонентов.
VD>Причем тут только компоненты непонятно. Component-based software engineering
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Заметка: Компонентная философия и реализация
AC>>COM был (и есть) слишком сложен и "массивен". .NET сделали проще AVK>Компонентная модель дотнета (и WinRT) существенно сложнее СОМ. Я уж не говорю о компонентной модели XAML, которая используется в WPF. СОМ на самом деле очень прост, но вот его использование в С++ весьма некомфортно, потому что язык под это неприспособлен. В рамках же дотнета СОМ весьма близок к родной компонентной модели.
Простота использования имелась ввиду, же.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[4]: Заметка: Компонентная философия и реализация
VD>1. Зачем весь этот ворох слов? Ведь тебе на выражение этой мысли хватило одного абзаца. VD>У меня просто перехватило усидчивости чтобы вылепить эту мысль.
Хотел чтобы у вас сложилось как можно более полное представление о КОП(там ведь есть не только пины), в частности о том какие перспективы открывает этот подход в теории, и о том как это может быть реализовано на практике. VD>2. Зачем для этого создавать новые языки и рантаймы? Для удобства использования.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Наследование интерфейсов в Java это не тоже самое, что несколько отдельных интерфейсов(как в COM).
Наследование — конечно нет, в СОМ наследование вообще отсуствует. А вот реализация интерфейсов вполне себе то же самое.
AVK>>В СОМ вызов QueryInterface, AC>Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: 1) как-то организовать получение GUID интерфейса конкретного компонента
И?
AC>2) оба взаимодействующих компонента должны получить таблицы методов(QueryInterface)
И?
AC>, 3) оба компонента должны проверить наличие функций "connection", и если таковые есть, вызвать.
И?
AC>В КОП это делается парой операторов("connect", "disconnect"), остальное забота рантайма.
Каких операторов? Смешались в кучу кони, люди. СОМ это компонентная модель, операторы это языковые сущности. Ничто не мешает создать язык с парой операторов, работающий с СОМ. Или даже язык, который в QueryInterface со всеми танцами превращает обычную операцию приведения типов.
AVK>>в жабе и дотнете операция приведения типа. AC>Причём здесь приведение типа?
Притом, что это семантический эквивалент QueryInterface.
AC> Оно лишь, даёт возможность скрыть/показать часть полей объекта.
Приведение к интерфейсу к полям вообще никакого отношения не имеет — интерфейс поля не содержит, только методы. И операция приведения семантически означает запрос определенного контракта с контролем его наличия. Т.е. ровно то же самое, что делает QueryInterface и твои мифические connect/disconnect. Причем этот вариант существенно более гибок, так как не требует реактивности в обязательном порядке (но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера).
AVK>>Без проблем реализуется поверх СОМ, дотнета и джавы. AC>В КОП поддерживается "из коробки".
КОП это парадигма. Никакой коробки нет. Ну и в дотнете это тоже практически искаропки — про reactive extensions я уже писал. Для жабы наверняка тоже что то есть.
AC>Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса
Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка.
AC>К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит.
Проснись, все что ты хочешь уже есть.
AC>Наверно автор писал о том как это делают обычно
Мне больше кажется, что автор просто не разобрался в том, что же такое СОМ. Потыркался в васике с компонентами и решил, что он уже все знает.
AVK>>http://en.wikipedia.org/wiki/WinRT#Services — пункты 2.1 AC>Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом.
И что?
AC>В КОП тоже есть метаданные, но в отличии от, нет необходимости тащить в пакет(в терминах Java) описание каждого метода и класса, достаточно набора сигнатур типов интерфейсов. Если тип(сигнатура) интерфейса сервера и клиента(в терминах COM, в КОП явного разделения нет) совпадает, значит типы методов(аргументов-результатов) и свойств так же совпадают.
Это какая то реализационная муть, которая к дизайну компонентной модели вообще никакого отношения не имеет.
AC> К тому же проверка сигнатуры выполняется только при подключении интерфейса, а не для каждого вызова метода.
А ты думаешь в WinRT она выполняется при каждом вызове? Или что у методов нет токенов (это твои сигнатуры так на самом деле называются)?
AVK>>Нет, это стандарт, позволяющий стороннему коду анализировать метаданные бинов. AC>JavaBeans, не нашёл про анализ метаданных
А меня тоже ссылки надежные есть. Так что давай лучше оперировать фактами, а не давать ссылки черт знает куда.
А факты ведь упрямая. Реактивное программирование прекрасно работает и без компонентов (хотя может и с ними). Соответственно приплетать его к компонентному подходу смысла не имеет.
Так же расстрою тебя еще одним фактом. Создавать ПО на базе одних лишь компонентов физически невозможно. Компоненты имеют смысл только там где требуются относительно большие блоки.
Скажу больше, компонентные технологии область довольно хорошо разработанная и революциями в ней не пахнет.
Лично я увлекался этим делом где-то в середине 90-х. Этот подход сулил серьезные бенефиты в области корпоративных систем (которые тогда были востребованы). Но чем больше я узнавал в этой области, тем больше понимал, что это не более чем полезный прием программирования. И самого программирования (т.е. написания большого количества кода) он не отменяет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Хотел чтобы у вас сложилось как можно более полное представление о КОП
Давай начнем с того, что КОП я занимался без малого 10 лет. Стало быть, если ты и правда придумал что-то новое, то не стоит называть это КОП, так как термин уже использован.
AC>(там ведь есть не только пины), в частности о том какие перспективы открывает этот подход в теории, и о том как это может быть реализовано на практике.
В теории вообще все давно известно. На любом полном по Тьюрингу языке можно написать любую программу, если конечно хватит сил и программа не рассыпется от багов, или не станет полностью непонятной. По сему людей интересуют лишь способы упростить программирование теряя при этом минимум производительности конечного приложения.
VD>>2. Зачем для этого создавать новые языки и рантаймы? AC>Для удобства использования.
AVK>Наследование — конечно нет, в СОМ наследование вообще отсуствует. А вот реализация интерфейсов вполне себе то же самое.
Так мы же про интерфейсы, а не про их реализацию. AVK>>>В СОМ вызов QueryInterface, AC>>Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: AVK>И? AVK>И? AVK>И?
И это сложнее чем использовать готовое, например. AVK>Каких операторов? Смешались в кучу кони, люди. СОМ это компонентная модель, операторы это языковые сущности. Ничто не мешает создать язык с парой операторов, работающий с СОМ. Или даже язык, который в QueryInterface со всеми танцами превращает обычную операцию приведения типов.
COM мало распространён, не целесообразно делать язык только для него. Я хочу чтобы это работало на(поверх) JVM(это ООП), и возможно в будущем на x86. То есть решение должно быть более обобщённым чем просто настройка над COM. AVK>>>в жабе и дотнете операция приведения типа. AC>>Причём здесь приведение типа? AVK>Притом, что это семантический эквивалент QueryInterface. QueryInterface, Java — 8. Преобразование типов. AC>> Оно лишь, даёт возможность скрыть/показать часть полей объекта. AVK>Приведение к интерфейсу к полям вообще никакого отношения не имеет — интерфейс поля не содержит, только методы.
Виноват исправлюсь, конечно же методы. AVK>И операция приведения семантически означает запрос определенного контракта с контролем его наличия.
Всё таки наверно эта операция семантически означает именно приведение типа, в процессе которого может выполнятся(а может и не выполнятся, если это происходит компилтайм) запрос и контроль. AVK>Т.е. ровно то же самое, что делает QueryInterface
QueryInterface делает именно запрос, он не выполняет приведение. AVK>и твои мифические connect/disconnect.
А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса. В процессе которых может выполнятся запрос и не может приведение(типы интерфейсов не наследуются). AVK>Причем этот вариант существенно более гибок, так как не требует реактивности в обязательном порядке
В КОП реактивность также не требуется(тем более в обязательном порядке), но поддерживаться на уровне ЯП. AVK>(но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера). Это похоже на урезанный Erlang, простым в использовании я бы это не назвал. AC>>В КОП поддерживается "из коробки". AVK>КОП это парадигма. Никакой коробки нет.
В обсуждаемой реализации, уточняю. AC>>Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса AVK>Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка.
Я этого не утверждал. AC>>К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит. AVK>Проснись, все что ты хочешь уже есть.
Есть только кусочками в разных местах, я хочу собрать всё это воедино. AC>>Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом. AVK>И что?
И это значит что мы обсуждаем практически тот же, старый добрый COM, а не новую технологию программирования от MS, как предполагалось выше. AC>>В КОП тоже есть метаданные, но в отличии от, нет необходимости тащить в пакет(в терминах Java) описание каждого метода и класса, достаточно набора сигнатур типов интерфейсов. Если тип(сигнатура) интерфейса сервера и клиента(в терминах COM, в КОП явного разделения нет) совпадает, значит типы методов(аргументов-результатов) и свойств так же совпадают. AVK>Это какая то реализационная муть, которая к дизайну компонентной модели вообще никакого отношения не имеет.
Это было маленькое отступление о метаданных, в обсуждаемой реализации КОП. AC>> К тому же проверка сигнатуры выполняется только при подключении интерфейса, а не для каждого вызова метода. AVK>А ты думаешь в WinRT она выполняется при каждом вызове? Или что у методов нет токенов (это твои сигнатуры так на самом деле называются)? Так утверждает википедия:
Когда среда CLR исполняет CIL она делает проверку того, что метаданные вызываемого метода совпадают с метаданными, хранящимися в вызывающем методе. Это гарантирует, что метод может быть вызван именно с корректным числом параметров и именно с корректными типами параметров.
Как оно реально работает, я не знаю.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Заметка: Компонентная философия и реализация
VD>Давай начнем с того, что КОП я занимался без малого 10 лет. Стало быть, если ты и правда придумал что-то новое, то не стоит называть это КОП, так как термин уже использован.
Это не что-то новое, это до/пере пиленое классическое КОП(с компонентами, интерфейсами и всяким таким).
Предложи другое название AC>>(там ведь есть не только пины), в частности о том какие перспективы открывает этот подход в теории, и о том как это может быть реализовано на практике. VD>В теории вообще все давно известно. На любом полном по Тьюрингу языке можно написать любую программу, если конечно хватит сил и программа не рассыпется от багов, или не станет полностью непонятной. По сему людей интересуют лишь способы упростить программирование теряя при этом минимум производительности конечного приложения.
Честно, три раза прочитал, не понял. Теории не нужны, что ли?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[9]: Заметка: Компонентная философия и реализация
AC>>Грубо говоря, для получения таблицы методов, как в COM'е, и... VD>Так и в чем тогда разница?
1)Грубо говоря(так как это может быть реализовано и без всяких таблиц методов), подключающийся компонент передаёт другому таблицу экспортируемых методов и получает от другого таблицу импортируемых(экспортируемых другим) методов, т.е. компоненты обмениваются таблицами(а не один передаёт другому как в COM). VD>>>и автоматического оповещения связанных компонентов. AC>>... да, для "оповещения" связывающихся компонентов. VD>Вот и раскрой этот момент по подробнее.
2)Компоненты, устанавливающие/разрывающие связь, получают извещение в виде вызова специальных методов, что позволяет им реагировать на эти события. VD>>>Причем тут только компоненты непонятно. AC>>Component-based software engineering VD>А меня тоже ссылки надежные есть.Так что давай лучше оперировать фактами, а не давать ссылки черт знает куда. VD>А факты ведь упрямая. Реактивное программирование прекрасно работает и без компонентов (хотя может и с ними). Соответственно приплетать его к компонентному подходу смысла не имеет.
Компоненты с реактивным программированием лучше чем компоненты без. VD>Так же расстрою тебя еще одним фактом. Создавать ПО на базе одних лишь компонентов физически невозможно.
Наверно так думали о про ООП во времена C++, но потом появилась Java, Ruby etc. VD>Компоненты имеют смысл только там где требуются относительно большие блоки.
Почему маленькие блоки не имеют смысла? VD>Скажу больше, компонентные технологии область довольно хорошо разработанная и революциями в ней не пахнет.
Откуда такая уверенность? VD>Лично я увлекался этим делом где-то в середине 90-х. Этот подход сулил серьезные бенефиты в области корпоративных систем (которые тогда были востребованы). Но чем больше я узнавал в этой области, тем больше понимал, что это не более чем полезный прием программирования. И самого программирования (т.е. написания большого количества кода) он не отменяет.
Сейчас, в своём текущем виде, да. Но и то, по сравнению с 90-ми КОП существенно развилось(например в том же .NET), и теперь помогает писать меньше "большого количества кода".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Какие ж они глобальные? Это конечно не чистое ФП, когда "состояние программы это состояние всех функций", но чтобы один компонент смог изменить другой он должен: 1) иметь соответствующий интерфейс; 2) в принципе "знать"(знать имя или как-то получить хендл) о другом. К тому же другой компонент может и не разрешить себя изменять.
ФП — это когда все состояние передается в качестве аргументов функций. Если есть глобальное состояние, то это уже не ФП.
То что описываешь ты — это императивное программирование и ООП, в частности.
Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления.
Интерфейсы вообще никак не связаны с состоянием. Можно легко создать интерфейс не меняющий состояния объектов.
А вот изменение компонента компонентом — это изменение состояния объектов, что уже 100% не ФП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AVK>>>>В СОМ вызов QueryInterface, AC>>>Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: AVK>>И? AVK>>И? AVK>>И? AC>И это сложнее чем использовать готовое, например.
Ты по прежнему не можешь уловить разницу между компонентной моделью и конкретным средством создания компонентов.
AC>COM мало распространён
Решил КО побыть? Что ты хотел сказать?
AVK>>Т.е. ровно то же самое, что делает QueryInterface AC>QueryInterface делает именно запрос, он не выполняет приведение.
В чем разница?
AC>А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса.
В чем разница?
AVK>>(но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера). AC>Это похоже на урезанный Erlang, простым в использовании я бы это не назвал.
Статья, мягко говоря, так себе. Начни лучше с этого — http://channel9.msdn.com/Events/MIX/MIX10/FTL01
AC>>>Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса AVK>>Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка. AC>Я этого не утверждал.
Это напрямую следует из твоего утверждения, что предложенное тобой не может быть реализовано поверх СОМ с удобным синтаксисом.
AC>>>Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом. AVK>>И что? AC>И это значит что мы обсуждаем практически тот же, старый добрый COM, а не новую технологию программирования от MS, как предполагалось выше.
Практический вывод из этого какой?
AVK>>А ты думаешь в WinRT она выполняется при каждом вызове? Или что у методов нет токенов (это твои сигнатуры так на самом деле называются)? AC>Так утверждает википедия: AC>[q]Когда среда CLR исполняет CIL она делает проверку того, что метаданные вызываемого метода совпадают с метаданными, хранящимися в вызывающем методе.
В момент JIT компиляции она это делает, а не при непосредственном выполнении. Причем уже в IL фигурирует токен метода, а не его метаданные. Метаданные хранятся отдельно. И не читайте русскую википедию, она гадость.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AC>>..."состояние программы это состояние всех функций"... VD>Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления.
От сюда:
Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>>>..."состояние программы это состояние всех функций"... VD>>Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления. AC>От сюда: AC>
AC>Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Да там горе-переводчик криво перевел. В оригинале, на который ссылка там же: "The global state of the system is carried into all functions and comes out from all functions.".
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
VD>>Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления. AC>От сюда: AC>
AC>Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Очень много в наши дни непроверенной пурги. На хабре его выше крыши. Так что читай этот ресурс с осторожностью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Заметка: Компонентная философия и реализация
AVK>Ты по прежнему не можешь уловить разницу между компонентной моделью и конкретным средством создания компонентов.
Скромно напоминаю: мы обсуждаем компонентную модель(и средства создания компонентов) хоть и похожую на COModel, но всё таки отличающеюся от неё. И чтобы устранить эти отличия, т.е. привести обсуждаемую модель к COM, т.е. чтобы обсуждаемая модель работала поверх COM, нужно сделать "И?И?И?" и ещё много чего. AC>>COM мало распространён AVK>Спасибо, насмешил.
Всяко меньше чем JVM. AVK>>>Притом, что это семантический эквивалент QueryInterface. AC>>QueryInterface, Java — 8. Преобразование типов. AVK>Решил КО побыть? Что ты хотел сказать?
Что это разные вещи и семантически, и синтаксически. AC>>QueryInterface делает именно запрос, он не выполняет приведение. AVK>В чем разница?
Как разница между словами "получить" и "преобразовать". Как бы, похоже, но не то. AC>>А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса. AVK>В чем разница?
Например, в процессе: преобразование интерфейса сложнее(состоит из большего числа логических действий) чем получение интерфейса, а подключение интерфейса сложнее чем преобразование.
Или например, в исходном и конечном состоянии: в первом случае изначально есть один интерфейс, в конце другой; во втором изначально нет ни одного интерфейса(есть только GUID интерфейса), в конце есть интерфейс(в виде таблицы методов); в третьем(для connect) изначально есть имя интерфейса, имя/хендл компонента и первая(экспортируемая) часть реализации интерфейса, в конце есть вторая(импортирования) часть реализации интерфейса, плюс выполнена функция-событие подключения. AC>>Это похоже на урезанный Erlang, простым в использовании я бы это не назвал. AVK>Статья, мягко говоря, так себе. Начни лучше с этого — http://channel9.msdn.com/Events/MIX/MIX10/FTL01
Спасибо, вечером посмотрю. AVK>>>Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка. AC>>Я этого не утверждал. AVK>Это напрямую следует из твоего утверждения, что предложенное тобой не может быть реализовано поверх СОМ с удобным синтаксисом.
Ох-хох, этого я точно не утверждал. "Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса и поддержки рантайма, для этого будет нужна куча соглашений..." — написал я. Как из этого следует, что удобный синтаксис и рантайм не могут быть реализованы по верх COM'а? AC>>И это значит что мы обсуждаем практически тот же, старый добрый COM, а не новую технологию программирования от MS, как предполагалось выше. AVK>Практический вывод из этого какой?
эта версия КОП != COM & WinRT AC>>[q]Когда среда CLR исполняет CIL она делает проверку того, что метаданные вызываемого метода совпадают с метаданными, хранящимися в вызывающем методе. AVK>В момент JIT компиляции она это делает, а не при непосредственном выполнении. Причем уже в IL фигурирует токен метода, а не его метаданные. Метаданные хранятся отдельно. И не читайте русскую википедию, она гадость.
Токен проверяется при каждом вызове?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[4]: Заметка: Компонентная философия и реализация
DM>И это тоже уже реализовано в DirectShow, например. Как раз на базе СОМ. Там пины так и называются пинами. Имеют четкие интерфейсы и т.д. Есть графические среды для создания графов из таких компонентов, в том числе с генерацией кода.
А где реклама одного из них?
=============
Ясен пень, что идея соединения через "пины" с последующим построением приложений из "кубиков" на поверхности. Но DirectShow слишком уж ограниченный для общих нужд, как и любая другая подобная система, где типы пинов заданы "сверху".
Re[4]: Заметка: Компонентная философия и реализация
Здравствуйте, VladD2, Вы писали:
VD>Наконец то кто-то смог выявить в этом тексте рациональное зерно. VD>Если принять твою мысль за истинную, то возникает два вопроса: VD>1. Зачем весь этот ворох слов? Ведь тебе на выражение этой мысли хватило одного абзаца.
Согласен, автору стоило самому сначала разобраться, где именно на его "модели" полезно было бы сфокусироваться и почему. Ведь всё аналогичное уже есть, надо было лишь показать предполагаемые бонусы.
VD>У меня просто перехватило усидчивости чтобы вылепить эту мысль. VD>2. Зачем для этого создавать новые языки и рантаймы?
Для поддержки необходимых ограничений, ес-но.
В дотнете пин можно упрощенно представить как объект со всего одним событием с одной стороны (выходной пин), и функциональный объект с другой (входной пин). Вот почему я упомянул реактивное программирование — это оно есть. Разница лишь в том, что это реактивное программирование приспособлено для КОП. Т.е. вместо объектов с кучей выходных пропертей (и событий об изменении к ним) с одной стороны и кучей методов (или входных пропертей) с другой, мы переходим к компонентам с кучей пинов с обоих сторон. Что это даёт? Да ничего нового, если смотреть чисто с филосовской точки зрения — биндинг в дотнете предоставляет аналогичные возможности... но очень много, есть вспомнить, что речь о статически-компиллируемых языках. В описанном мною виде каждый пин сам себе является Property/Event/MemberDescriptor, то бишь биндинг может происходить в рантайм или compile-time в типизированной манере, с соблюдением жестких контрактов, в отличие от предлагаемо нетипизированной возни через рефлексию + ComponentModel в дотнете (с пролетающими мимо системы типов, но тем не менее неразрывными связями некоего property Xxx и 2-х events к нему: onXxxChanging/onXxxChanged).
В итоге становится легко строить программы "топологически", просто соединяя пины подходящих типов, без вероятности допустить ошибку в (сугубо умозритрительном на сегодня) контракте для биндинга. Ну и лаконичность, опять же. Сейчас обслуживание одного пина настолько размазано по коду, насколько вообще возможно нарушить SRP, увы.
============
См. всевозможные костыли-вариации на тему биндинга в дотнете. Фиг с ней уже, с ComponentModel... первый блин комом.. Ну ей-богу, без слёз смотреть на этот XML-роутинг событий в WPF невозможно. Если бы электронщики так же плутали в 3-х соснах при роутинге сигналов, мы бы до сих пор не продвинулись дальше 4-хразрядных калькуляторов. См. современные языки для реактивного программирования (то бишь для разработки аппаратуры), типа VHDL: D1: NAND2 port map (a => a, b => b, c => s1); Эквивалентный код в C# или WPF-XML просто нечитабелен. То бишь имеющиеся языки де-факто не приспособлены для компонентного программирования.
И да, мы знаем, что уж на Немерле можно много чего, было бы желание. )
Вот вам еще одна одна тема для библиотек. Жаль, что существующий WPF не натянешь на предполагаемую модель, нужно разработать с 0-ля. А для ComponentModel, WPF и прочих недо-КОП legacy code сделать кодогенератор оберток для уже существующих компонент под новую модель.
