1) На парадигму, это, извини, не тянет.
2) Это действительно по сути разновидность паттерна Прокси
3) Есть реализации, где проксирование осуществляется автоматически
4) Наиболее близкая к твоим желаниям реализация есть в .NET. Там это называется TransparentProxy/RealProxy. В этом случае RealProxy является как раз тем, что ты называешь ссылкой. Он не реализует никакого интерфейса прикладного слоя и пишется один на некий фреймворк. Подробнее можешь посмотреть здесь.
TransparentProxy это автоматический объект, создаваемый средой исполнения и умеющий на лету менять набор поддерживаемых публичных контрактов. Служит он для прозрачного использования RealProxy в прикладном коде.
Так что твое счастье уже осуществилось
5) Идея с прозрачной заменой локальных коммуникаций на сетевые плохая.
6) Реализация подобных вещей на низком уровне, вроде тех же TP/RP в .NET создает серьезнейшие проблемы в работе оптимизатора.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, savinov, Вы писали:
AVK>1) На парадигму, это, извини, не тянет. AVK>2) Это действительно по сути разновидность паттерна Прокси
Это вовсе не так. Посто ты проецируешь все ниезвестное, на то, что тебе известно (не только ты конечно).
Более конкретно:
— Даже, если прокси эффективно имитирует интерфейс целевого объекта, то все равно в программе мы используем прокси и храним ссылку на прокси. А что, если мы захтим использовать другой прокси? Менять объявления во всей программе? Наверное и это можно как-то автоматизировать. Можно, например, взять паяльник и изменить что-то в процессоре. Но мы же говорим не об этом.
— Прокси является таким же объектом как и все остальные, а потому вместо задачи "как представить наш целевой объекто" мы должны заново решать задачу "как представить наш прокси". Т.е. прокси ничего не решает. Чувствуешь? Совершенно ничего. Вместо ссылки на объект получаем ссылку на прокси. Ну и что? Мне вообще не нужна системная ссылка. Мне нужна моя собственная, в моем собственом формате. А вдруг эта ссылки изменится через пару минут и объект (в т.ч. прокси) будет в другом месте и иметь другую ссылку, что я тогда должен делать?
— Прокси опосредует только один целевой объект, тогда как в КОП много объектов могут жить в контексте, под защитой одного и того же объекта. Другими словами, запросы на доступ ко многим целевым объектам проходят через один и тот же объект (контейнер, граница пространства, scope и т.п.) Ты же понимаешь, что контейнер это вовсе не прокси.
— В КОП целевые объекты могут иметь разные классы и иметь один и тот же тип ссылки. Сделать прокси настолько же универсальным довольно сложно.
— Прокси это не свойство языка (в частности, не часть ООП). Это просто паттерн, который можно реализовать на чем угодно. Например, в Яве есть динамические прокси, в ДотНет есть прозрачные прокси. Это просто сбоку привинченный механизм. КОП же реализует не просто примочку, а определнную концепцию, видение как должна быть устроена система.
— Концепт осуществляет опосредование как через ссылки, так и через объекты (в двух направлениях) с помощью двойственных методов. Один методы для входа внутрь извне, а другие для использования изнутри. В хорошей системе так всегда и проектируется, но просто все вручную. Ну а прокси имеет очень простое предназначение, т.е. это паттерн, а не принцип программирования.
— Цель КОП не состоит в проксировании. Его цель состоит в создании системы обозначений для объектов (и прозрачного доступа по ней). Ясно, что с проки это не связано, хотя прокси наверное можно было бы как-то прилепить.
AVK>3) Есть реализации, где проксирование осуществляется автоматически
Ну и что? Причем тут вообще проксирование. КОП в этом смысле гораздо ближе к АОП, где очень хорошо реализован прозрачный доступ. Ты же не будешь отверждать, что АОП это и есть проксирование? А КОП еще дальше находится от проксирования, чем АОП.
AVK>4) Наиболее близкая к твоим желаниям реализация есть в .NET. Там это называется TransparentProxy/RealProxy. В этом случае RealProxy является как раз тем, что ты называешь ссылкой. Он не реализует никакого интерфейса прикладного слоя и пишется один на некий фреймворк. Подробнее можешь посмотреть здесь.
Спасибо, посмотрел. Это действительно удобный механизм, но предназначенный для других целей (см. выше).
AVK>TransparentProxy это автоматический объект, создаваемый средой исполнения и умеющий на лету менять набор поддерживаемых публичных контрактов. Служит он для прозрачного использования RealProxy в прикладном коде. AVK>Так что твое счастье уже осуществилось
К сожалению, нет
AVK>5) Идея с прозрачной заменой локальных коммуникаций на сетевые плохая.
Речь не идет и конкретных вещах типа сетевые коммуникации или локальные. Речь идет о виртуализации доступа как такового. А лучше эта виртуализация или хуже будет реализована это уже проблема инженеров. Например, при разработке класса Account нужно абстрагироваться от того, где и как он будет храниться, что дает возможность использовать его независимо от этого, например, account.getBalance(). Заметь, в этом коде нет никакх указаний на то, где находится этот счет, но в КОП гарантируется, что он отработает и вернет остаток счета. Более того, это код не изменится, если мы посадим это счет в локальную БД, в сервер приложений, в глобальную/локальную кучу или еще куда-то, куда нам скажут. Ни сам класс Account, ни код, который его использует не знают где объект реально находится и как к нему будет осуществляться доступ.
AVK>6) Реализация подобных вещей на низком уровне, вроде тех же TP/RP в .NET создает серьезнейшие проблемы в работе оптимизатора.
Опять ты проецируешь на то, что тебе известно. Какая мне разница как это будет оптимизировано? Тебя волнует хорошо или плохо оптимизируется код в АОП? Ты пойми сперва принцип, а до оптимизации кода еще очень далеко. А принцип состоит в том, что нужно виртуализировать всю систему и отвязать ее от реальности. Например, скажи, будь добр, что ты будешь делать, если тебя сборщик мусора от твоего любимого ДотНет не устроит? А в КОП ты всегда имеешь возможность организовать свою собственную систему координат для обозначения объектов со своими жизненными принципами. А в соответствии с твоей логикой АОП это тоже простое проксироване, а не парадигма. Парадигм вообще в этом смысле не существует. ООП это просто объявление структуры данных (что было и раньше), а также использование процедура, где первый параметр указывает на целевой объект. Ну а полиморфизм можно реализовать через косвенные вызовы и виртуальную таблицу. Все это было и раньше. Ничего нового нет. Так в чем же тогда проблема. А в том, что ООП это не виртуальные функции, а взгляд на систему как состоящую из объектов. Соответственно КОП как парадигма это взгляд на систему как состоящую из двух типов элементов: объектов и ссылок. Если ты это поймешь, то далее все пойдет гораздо проще. А если будешь думать как реализовать это имеющимися средствами (т.е. проецировать на существующие значиня), то конечно проекция получится вырожденной, т.е. ничего не увидишь.
Здравствуйте, savinov, Вы писали:
AVK>>1) На парадигму, это, извини, не тянет. AVK>>2) Это действительно по сути разновидность паттерна Прокси
S>Это вовсе не так.
Именно так.
S> Посто ты проецируешь все ниезвестное, на то, что тебе известно (не только ты конечно).
Давай ты не будешь делать выводы о том, что и куда я проецирую, тогда я не буду делать выводы о том, что и куда проециркешь ты, ОК? Начни с того, что собеседники как минимум не глупее тебя и способны понять твои идеи.
S>- Даже, если прокси эффективно имитирует интерфейс целевого объекта, то все равно в программе мы используем прокси и храним ссылку на прокси.
Внешне, на уровне исходного кода это никак не заметно.
S> А что, если мы захтим использовать другой прокси?
Зачем? TransparentProxy не содержит никакой логики, это просто инструментальный мост. На уровне конструкций языка его не существует, это фича CLR. Если тебе надо менять прикладной код, который будет стоять на проходе, то это легко и непринужденно реализуется применением соотв. паттернов внутри RealProxy.
S> Менять объявления во всей программе?
Нет.
S> Наверное и это можно как-то автоматизировать. Можно, например, взять паяльник и изменить что-то в процессоре. Но мы же говорим не об этом.
Не надо ничего паяльником, все уже есть.
S>- Прокси является таким же объектом как и все остальные,
Нет, TP объектом не является. Это именно что некоторое подобие динамически типизированной ссылки.
S> а потому вместо задачи "как представить наш целевой объекто" мы должны заново решать задачу "как представить наш прокси".
Нет.
S> Т.е. прокси ничего не решает. Чувствуешь?
Нет.
S> Совершенно ничего. Вместо ссылки на объект получаем ссылку на прокси.
Какая разница что мы там получаем, если для прогрнаммиста это выглядит абсолютно прозрачно? TransparentProxy, на то она и transparent.
S> Ну и что? Мне вообще не нужна системная ссылка. Мне нужна моя собственная, в моем собственом формате.
Зачем? Формат тебе зачем? Тебе шашечки или ехать?
S> А вдруг эта ссылки изменится через пару минут и объект (в т.ч. прокси) будет в другом месте и иметь другую ссылку, что я тогда должен делать?
В примерах к ремоутингу есть и реализация пула объектов, как ты тут рассказывал, и прозрачное перенаправление вызовов от одной и той же ссылки к разным серверам. Ты бы, вместо того чтобы подозревать меня, что я что то там не понял, попробовал бы поверить в то, что я знаю о чем говорю. Еще раз — механика TP/RP на 100% обеспечивает все, о чем ты тут писал и много чего другого.
S>- Прокси опосредует только один целевой объект,
Нет. RP опосредует любые типы, для которых он создал TP. В частности, в ремоутинге для любого типа объектов существует единственная реализация RP, а именно System.Runtime.Remoting.Proxies.RemotingProxy.
S> тогда как в КОП много объектов могут жить в контексте, под защитой одного и того же объекта.
TP/RP это позволяют. А еще они, к примеру, позволяют автоматически, без участия программиста, менять RP в зависимости от некоего внешнего произвольного контекста (курить ContextBoundObject). Ты о чем то подобном задумывался?
S> Другими словами, запросы на доступ ко многим целевым объектам проходят через один и тот же объект (контейнер, граница пространства, scope и т.п.)
Ага. Только что ты описал remoting в .NET.
S> Ты же понимаешь, что контейнер это вовсе не прокси.
Конечно нет. Только вот контейнер намного лучше очерчивать по усмотрению прикладного программиста, а не разрабочика языка, что нам .NET и предоставляет. В remoting контейнером является домен приложения, в CBO контекст формируется специальным атрибутом и т.п.
S>- В КОП целевые объекты могут иметь разные классы и иметь один и тот же тип ссылки.
И в .NET это возможно. А еще там возможно, что тип ссылки на ходу сменится. Потому что castclass TP тоже перехватывается.
S> Сделать прокси настолько же универсальным довольно сложно.
Нет.
S>- Прокси это не свойство языка (в частности, не часть ООП).
В случае .NET это свойство рантайма. Это еще глубже, чем свойство языка.
S>Ну а прокси имеет очень простое предназначение, т.е. это паттерн, а не принцип программирования.
Паттерн от парадигмы (что такое принцип программирования, я не знаю) отличается только универсальностью и известной применимостью. К примеру, ООП в свое время был тоже паттерном, а метаклассы, являясь в некоторых языках первоклассной сущностью, в других являются просто паттерном.
S>- Цель КОП не состоит в проксировании.
А цель и не может состоять в проксировании. Это всего лишь метод..
AVK>>3) Есть реализации, где проксирование осуществляется автоматически
S>Ну и что? Причем тут вообще проксирование.
При том, что это прекрасный метод для достижения означенных тобой целей.
S> КОП в этом смысле гораздо ближе к АОП,
А АОП, как правило, и реализуется ввиде проксей или прямой модификации кода.
S> где очень хорошо реализован прозрачный доступ. Ты же не будешь отверждать, что АОП это и есть проксирование?
А я и не утверждаю, что КОП это проксирование. КОП это паттерн, ровно как и АОП. Видишь ли, паттерн совсем не обязан быть примитивным. В GoF паттерны простые, потому что это азбука. А, к примеру, паттерн MVC уже существенно сложнее и тянет за собой некоторые философские вопросы. Есть и еще более сложные паттерны.
Ты пытаешься, манипулируя терминами, показать, что ты придумал что то новое. Пока же получается, что придумал ты исключительно новый термин.
S>Спасибо, посмотрел. Это действительно удобный механизм, но предназначенный для других целей (см. выше).
Каких других? Целей там масса. Если даже списать большую часть на ремоутинг (он, кстати, как раз соответствует тем примерам применения, что ты приводил), то остается еще ContextBoundObject, который в самом фреймворке никак не используется. Вот что сказано в MSDN:
Objects that reside in a context and are bound to the context rules are called context-bound objects. A context is a set of properties or usage rules that define an environment where a collection of objects resides. The rules are enforced when the objects are entering or leaving a context. Objects that are not context-bound are called agile objects.
Замени контекст на контейнер и получишь то же самое, что ты тут пишешь. Только, в отличие от твоих вариантов, эта механика значительно гибче и позволяет сделать больше.
Но как средство для экспериментов с твоей теорией и создания примеров, демонстрирующих преимущество пропагандируемого тобой подхода, оно подходит превосходно. Все возможности, о которых ты говоришь, оно реализует без проблем.
AVK>>TransparentProxy это автоматический объект, создаваемый средой исполнения и умеющий на лету менять набор поддерживаемых публичных контрактов. Служит он для прозрачного использования RealProxy в прикладном коде. AVK>>Так что твое счастье уже осуществилось
S>К сожалению, нет
К сожалению да
S>Речь не идет и конкретных вещах типа сетевые коммуникации или локальные. Речь идет о виртуализации доступа как такового. А лучше эта виртуализация или хуже будет реализована это уже проблема инженеров.
Дело не в реализации. Проблемы значительно фундаментальнее. И пока латентность и надежность сетевых коммуникаций не приблизится к показателям локальной шины компьютера, никакой реализацией эти проблемы не решить.
S> Например, при разработке класса Account нужно абстрагироваться от того, где и как он будет храниться, что дает возможность использовать его независимо от этого, например, account.getBalance().
Возможности абстракций не безграничны. Абстрагироваться можно от более менее сопоставимых вещей. Когда же параметры среды отличаются на несколько порядков, абстракция ни к чему хорошему не приведет.
S> Заметь, в этом коде нет никакх указаний на то, где находится этот счет, но в КОП гарантируется, что он отработает и вернет остаток счета.
При чем тут КОП? Это базовые вещи в проектировании, о них известно было несколько десятов лет назад. И существует очень много возможностей этого добиться.
AVK>>6) Реализация подобных вещей на низком уровне, вроде тех же TP/RP в .NET создает серьезнейшие проблемы в работе оптимизатора.
S>Опять ты проецируешь на то, что тебе известно.
Опять ты, вместо обсуждения проблемы, скатился на обсуждение моего понимания. Попробуй предположить, что кое чего не видишь именно ты.
S> Какая мне разница как это будет оптимизировано?
Тебе может и никакой. Но забывать об этом не следует. Возможность эффективно и параллельно выполняться то одна из важнейших возможностей любого решения.
S> Тебя волнует хорошо или плохо оптимизируется код в АОП?
Да.
S> Ты пойми сперва принцип, а до оптимизации кода еще очень далеко.
Принцип я уже давно понял.
S> А принцип состоит в том, что нужно виртуализировать всю систему и отвязать ее от реальности.
Знаешь сколько таких слоев виртуализации в типичной программе? Ничего нового в этом нет.
S> Например, скажи, будь добр, что ты будешь делать, если тебя сборщик мусора от твоего любимого ДотНет не устроит?
Не надо делать предположения о моих любимых.
S> А в КОП ты всегда имеешь возможность организовать свою собственную систему координат для обозначения объектов со своими жизненными принципами.
Ага. Вот в ремоутинге так и сделано. Там, вместо сборщика мусора, своя механика lifetime management.
S> А в соответствии с твоей логикой АОП это тоже простое проксироване, а не парадигма.
Нет у меня такой логики, это ты сам придумал.
S>Соответственно КОП как парадигма это взгляд на систему как состоящую из двух типов элементов: объектов и ссылок. Если ты это поймешь, то далее все пойдет гораздо проще.
Да понял я это уже давно. Это ты никак не поймешь, что ничего нового при этом я не увидел. Поверь, скажем функциональная парадигма на порядке дальше от ООП, чем твое предложение, и ничего, большинство тут затруднений с этим не имеет. Так что забудь о принципиальной непонимаемости твоего подхода.
S> А если будешь думать как реализовать это имеющимися средствами (т.е. проецировать на существующие значиня), то конечно проекция получится вырожденной, т.е. ничего не увидишь.
Вот чтобы проекция и не получалась вырожденной, давай, приводи примеры того, где твоя супеконцепция позволит получить бенефит. А потом мы посмотрим, справится ли с этим механика TP/RP. Пока что все приведенные тобой примеры эта механика на 100% реализует.
Здравствуйте, savinov, Вы писали:
S>Думаю, что от происхождения идеи ничего не зависит. Важна просто сама идея.
В серьёзной научной работе в самом начале всегда прямо или косвенно описывается происхождение идеи. Именно такой preface и позволяет определить контекст, к который нужно поместить описываемую дальше измышлятину. Вне контекста в научном мире ничто не существует.
S>Странно, почему тогда нет примеров, если КОП возникла как раз по первому варианту развития?
Тогда нужно просто вспомнить, с чего всё начиналось
V>>Желаю удачи в выдумывании убедительных иллюстративных примеров. Придумаете, заходите ещё. S>Спасибо. Если появятся, то обязательно зайду.
Подкину идейку. Информационные сущности бывают двух видов:
1. Объекты — это то, что может обладать идентичностью (и, следовательно, иметь какой-либо OID).
2. Не-объекты — это такие сущности, которые ничем, кроме как своим содержимым, не идентифицируются. Например: размер заработной платы, длина отрезка, наименование товара.
Такие не-объекты имеют важное свойство: они не умеют существовать самостоятельно. Они всегда существуют в рамках контекста (который, конечно, уже является объектом). Самое смешное, что не-объекты не обязательно принадлежат примитивным типам данных. Например, всякий суммовой показатель, кроме собственно числового значения, как правило, характеризуется валютой. Соответственно, натуральный показатель — единицей измерения. Даже со строками не всё так просто: в принципе, строковое значение может характеризоваться языком, на котором она написана.
Пример: увеличить зарплату (поле Salary) сотрудника emp на increase USD. Предполагается, что сотрудники, кроме всего прочего, характеризуются валютой взаиморасчётов (SalaryCurrency)
"Обычный" подход, в котором не-объекты не имеют структуры и пассивны:
emp->Salary += ConvertMoney(increase, new Currency("USD"), emp->SalaryCurrency);
Проблема в том, что такой метод не является себя-дурака-устойчивым. Рано или поздно забудется, что денежку нужно конвертнуть, и появится строчка типа:
emp->Salary += increase;
, которая будет исправно работать до тех пор, пока все зарплаты исчисляются в USD. При появлении первой рублёвой зарплаты система заглючит.
Можно, конечно, числовое поле Salary завернуть в программный интерфейс, но если таких числовых полей сотни, то это ж будут не классы, а большие коллекции маловразумительных методов. И, в конце концов, кто-нибудь что-нибудь всё равно забудет.
А можно было бы и так:
emp.Salary += Money(increase, new Currency("USD"));
При этом Salary — это, на самом деле не просто числовое поле, а некая обманка, физически состоящая из двух полей (значение и валюта) и принадлежащая к специальному классу Money, на котором определены арифметические операции, которые при необходимости сами конвертят валюты.
Что характерно, эти самые не-объекты — это даже не структуры в привычном понимании этого слова. Например, одно "физическое" поле Currency (валюта взаиморасчётов) может обслуживать и размер зарплаты, и премиальную ставку, и баланс лицевого счёта сотрудника.
-------------------
Короче, дарю этот иллюстративный пример. Если, конечно, он окажется КОПу по зубам.
Саму же идею не-объектов не дарю. Если эта нива ещё никем не вспахана, то пусть она будет моей
Voblin wrote: > Даже со строками не всё так просто: в принципе, > строковое значение может характеризоваться языком, на котором она написана.
Интересно. Сейчас в рамках Boost'а развивается проект Quan — библиотека
для контроля размерности физических величин.
У них пока рассматриваются только физические величины, то есть такой код:
Здравствуйте, Cyberax, Вы писали:
C>Voblin wrote: >> Даже со строками не всё так просто: в принципе, >> строковое значение может характеризоваться языком, на котором она написана. C>Интересно. Сейчас в рамках Boost'а развивается проект Quan — библиотека C>для контроля размерности физических величин.
Здравствуйте, Cyberax, Вы писали:
C>Интересно. Сейчас в рамках Boost'а развивается проект Quan — библиотека C>для контроля размерности физических величин. C>У них пока рассматриваются только физические величины, то есть такой код:
На мой взгляд, прикручивать размерности к C++ — не совсем здравая идея. Может быть, конечно, я и не прав, но мне больше понравился подход, реализованный в Fortress: http://research.sun.com/projects/plrg/fortress0785.pdf.
Кстати, единицами измерения дело не ограничивается. Например, набор атрибутов, составляющих адрес (Country, City, Street,...) тоже логично обрабатывать как единое целое и в рантайме иметь на всё это великолепие одну "псевдоссылку" Address.
Если посмотреть структуру БД, в которой ведутся какие-нибудь закупки/продажи, то очень часто во многих таблицах можно найти такие наборы полей: Price, Quantity, UnitID, Summ, CurrencyID, VATRate, VATSumm. При этом дело осложняется тем, что поля Price, Quantity, UnitID, Summ, VATRate, VATSumm сидят в таблице (и соответствующем ей классе) OrderDetails, а поле CurrencyID — в таблице Orders. Эти поля настолько повязаны взаимозависимостями, что так и хочется их объединить в один класс.
Так что, единицами измерения дело не ограничивается, хотя пара (Значение, Единица измерения) — это самый очевидный пример не-объекта так как любая скалярная величина — это всё-таки величина, и без указания единицы измерения не имеет ни физического, ни любого другого смысла.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, savinov, Вы писали:
AVK>1) На парадигму, это, извини, не тянет. AVK>2) Это действительно по сути разновидность паттерна Прокси
+1
AVK>3) Есть реализации, где проксирование осуществляется автоматически AVK>4) Наиболее близкая к твоим желаниям реализация есть в .NET. Там это называется TransparentProxy/RealProxy. В этом случае RealProxy является как раз тем, что ты называешь ссылкой. Он не реализует никакого интерфейса прикладного слоя и пишется один на некий фреймворк. Подробнее можешь посмотреть здесь. AVK>TransparentProxy это автоматический объект, создаваемый средой исполнения и умеющий на лету менять набор поддерживаемых публичных контрактов. Служит он для прозрачного использования RealProxy в прикладном коде. AVK>Так что твое счастье уже осуществилось
Вот именно.
Автор топика знаком с концепцией умных указателей (здесь), которой уже сто лет в обед?
С помощью перегрузки оператора "->" в C++ можно как раз добиться желаемого эффекта дополнительных промежуточных действий (при этом естественно все это может быть вложенным).
Об этом уже давно писалось в соотв. литературе.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, savinov, Вы писали:
S>> Совершенно ничего. Вместо ссылки на объект получаем ссылку на прокси.
S>> Ну и что? Мне вообще не нужна системная ссылка. Мне нужна моя собственная, в моем собственом формате.
AVK>Зачем? Формат тебе зачем? Тебе шашечки или ехать?
Это ключевой вопрос. Для понимания КОП нужно понять, что такое ссылка и для чего она нужна. Ну а разновидности прокси это всего лишь один из паттернов, наравне с многими другими языковыми и неязыковыми средствами, которые можно как-то приспособить для решения этой задачи. Так что сравнивать КОП с ними не имеет большого смысла. Это все равно, что сравнивать принципы архитектуры с лопатой. Я буду говорить, как надо строить дом, а ты будешь говорить, что все это можно и лопатой сделать. Причем самое интересное, что ты будешь прав, но я к этому мог бы добавить, что кроме лопаты есть еще экскаватор, отбойный молоток и др. средства. Но все это не имеет отношения к предмету разговора.
S>> А вдруг эта ссылки изменится через пару минут и объект (в т.ч. прокси) будет в другом месте и иметь другую ссылку, что я тогда должен делать?
AVK>В примерах к ремоутингу есть и реализация пула объектов, как ты тут рассказывал, и прозрачное перенаправление вызовов от одной и той же ссылки к разным серверам. Ты бы, вместо того чтобы подозревать меня, что я что то там не понял, попробовал бы поверить в то, что я знаю о чем говорю. Еще раз — механика TP/RP на 100% обеспечивает все, о чем ты тут писал и много чего другого.
Я тебя не подозреваю, а просто говорю, что твои познания имеют довольно далекое отношения к предмету обсуждения. У тебя есть один аргумент: это можно реализовать так-то. А я и не спорю, а верю тебе на слово. Более того, я могу еще предложить еще несколько основных и десяток модификаций того, как можно реализовать что-то подобное. Экстремальный пример состоит в использовании ассемблера. Другой пример, использование CORBA. Если хочется что-то свое, то легко можно написать свой moddleware для удаленных объектов. Но ведь это все как раз то, чего нам НЕ нужно, т.е. с чем мы боремся. И пока ты это не воспримешь, то извини, но я не могу сказать, что ты понял хотя бы цели КОП. Цель КОП состоит в описании ссылок и их функций наравне с объектами, которые они представляют.
S>>- Прокси это не свойство языка (в частности, не часть ООП).
AVK>В случае .NET это свойство рантайма. Это еще глубже, чем свойство языка.
Правильно, т.е. как раз то, что нам НЕ нужно. КОП направлен на создание своего собственного рантайма, своего собственного менеджера объектов, своего собственного формата ссылок, своей среды, своих контейнеров, своей виртуальном машины. Только пожалуйста, не отвечай, что это не нужно (ясно, что все эти функции обычно не будут реализовываться в полном виде). Просто попытайся понять цели КОП как они есть, а не исходя из существующих способов реализации систем, т.е. не проецируй идею на то, что уже известно.
S>>Спасибо, посмотрел. Это действительно удобный механизм, но предназначенный для других целей (см. выше).
AVK>Каких других? Целей там масса. Если даже списать большую часть на ремоутинг (он, кстати, как раз соответствует тем примерам применения, что ты приводил), то остается еще ContextBoundObject, который в самом фреймворке никак не используется. Вот что сказано в MSDN: AVK>
Objects that reside in a context and are bound to the context rules are called context-bound objects. A context is a set of properties or usage rules that define an environment where a collection of objects resides. The rules are enforced when the objects are entering or leaving a context. Objects that are not context-bound are called agile objects.
AVK>Замени контекст на контейнер и получишь то же самое, что ты тут пишешь. Только, в отличие от твоих вариантов, эта механика значительно гибче и позволяет сделать больше.
Ты описываешь свойства платформы, а я говорю о свойствах языка. Ты говоришь о способах реализации, а я говорю о целях реализации. Ты говоришь о механизмах, а я говорю о принципах проектирования. Вывод: мы говорим на разных языках.
Попытаюсь еще раз объяснить. КОП основан на описании ссылок и их функций. Я их не вижу в ДотНет (хотя ДотНет это не язык а платформа). Покажи мне какой язык позволяет моделировать ссылки и тогда можно будет что-то обсуждать. Нет ссылок — нет КОП, а есть ООП. Все остальное к вопросу не имеет отношения, поскольку это вопрос о возможности реализовать ту или иную концепцию на том или ином языке или на той или иной платформе. Экстремальное решение всегда существует — на ассемблере. Ну или попросить Микрософт и ребята встроят в это платформу или сразу в Windows.
S>> Например, при разработке класса Account нужно абстрагироваться от того, где и как он будет храниться, что дает возможность использовать его независимо от этого, например, account.getBalance().
AVK>Возможности абстракций не безграничны. Абстрагироваться можно от более менее сопоставимых вещей. Когда же параметры среды отличаются на несколько порядков, абстракция ни к чему хорошему не приведет.
Я вижу ты мыслишь с точки зрения подрядчика. Я не предлагаю ничего реализовать. Речь НЕ идет о сетях, памяти или процессоре. Речь идет о принципах программирования, т.е. о принципах написания программы. Можно мыслить программу в терминах объектов как учит ООП (опять же не говори о проблемах виртуальных функций или множественном наследовании). Ну а КОП предлагает мыслить программу в терминах ссылок и объектов. Т.е. в КОП ссылки легализуются и выходят из подполья (из рантайма) наружу так, что становятся такими же полноценными сущностями как и объекты. Если это не понять, то дальше нет смысла двигаться.
S>> А если будешь думать как реализовать это имеющимися средствами (т.е. проецировать на существующие значиня), то конечно проекция получится вырожденной, т.е. ничего не увидишь.
AVK>Вот чтобы проекция и не получалась вырожденной, давай, приводи примеры того, где твоя супеконцепция позволит получить бенефит. А потом мы посмотрим, справится ли с этим механика TP/RP. Пока что все приведенные тобой примеры эта механика на 100% реализует.
Я сразу скажу — справится. Но при этом добавлю: это также можно реализовать и другими способами. Извини, но твои аргументы "против" стандартны в том смысле, что сводятся к следующей фразе:
Вновь предложенный механизм можно реализовать так-то. И это будет проще, поскольку такие средства уже имеются и изучены, а для предложенного механизма еще нет.
С ними спорить глупо и бесполезно, поскольку так оно и есть. Ну например, по твоему ООП не было нужно, поскольку я и так могу на Си реализовать все это, причем быстрее и надежнее, поскольку Си уже есть, а С++ только в проекте. По твоему это аргумент против ООП, а по моему это вообще не имеет отношения к делу. Так что решай сам, будем ли мы обсуждать принципы программирования или возможность что-то реализовать помощью тех или иных платформ или паттернов.
Могу только повторить: укажи мне на подход, где бы могли бы описать свою собственную виртуальную систему обозначений объектов и доступа к ним. Если такой нет, то значит КОП как минимум оригинален. Тогда далее стоит вопрос зачем это нужно и полезно ли это. Здесь формальных доказательств быть не может. Но главный аргумент состоит в том, что ссылки являются такими же полноценными элементами программы как и объекты, которые они представляют. Поскольку там сосредоточено много функций, то необходимы средства для их описания (в этой же программе, а не с помощью к-л стандартной платформы).
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, savinov, Вы писали:
AVK>>1) На парадигму, это, извини, не тянет. AVK>>2) Это действительно по сути разновидность паттерна Прокси АХ>+1
Нет. Различия очевидны:
Прокси это ширма объекта.
КОП это подход к созданию виртуальной системы доступа к объектам.
Сравнение имеет ровно столько смысла, сколько например сравнение прокси и АОП.
AVK>>3) Есть реализации, где проксирование осуществляется автоматически AVK>>4) Наиболее близкая к твоим желаниям реализация есть в .NET. Там это называется TransparentProxy/RealProxy. В этом случае RealProxy является как раз тем, что ты называешь ссылкой. Он не реализует никакого интерфейса прикладного слоя и пишется один на некий фреймворк. Подробнее можешь посмотреть здесь. AVK>>TransparentProxy это автоматический объект, создаваемый средой исполнения и умеющий на лету менять набор поддерживаемых публичных контрактов. Служит он для прозрачного использования RealProxy в прикладном коде. AVK>>Так что твое счастье уже осуществилось
АХ>Вот именно.
Не хотелось бы, но приходится объяснять очевидные вещи, как например, разницу между языком и поддержкой на уровне платформы:
Прокси как ширма объекта, которая реализуется с помощью другого объекта.
Реализация различных "приятностей" на уровне той или иной платформы, например, динамических и прозрачных прокси, удаленных методов, контекстов и др. механизмов.
Язык это язык, а платформа это платформа.
АХ>Автор топика знаком с концепцией умных указателей (здесь), которой уже сто лет в обед? АХ>С помощью перегрузки оператора "->" в C++ можно как раз добиться желаемого эффекта дополнительных промежуточных действий (при этом естественно все это может быть вложенным). АХ>Об этом уже давно писалось в соотв. литературе.
Добиться желаемого эффекта с помощью умных указателей (так же как и с помощью многочисленных других существующих средств) нельзя. Знакомство же с такими механизмами полезно, чтобы понять мотивацию, а также недостатки существующих механизмов.
АХ>Про Nemerle я вообще молчу .
Вы хотите сказать, что Немерле есть средства описания ссылок? Если нет, тогда это просто проявление эрудиции, а КОП это прост повод.
S>Добиться желаемого эффекта с помощью умных указателей (так же как и с помощью многочисленных других существующих средств) нельзя. Знакомство же с такими механизмами полезно, чтобы понять мотивацию, а также недостатки существующих механизмов.
Так ты бы перечислил недостатки существующих механизмов.
АХ>>Про Nemerle я вообще молчу .
S>Вы хотите сказать, что Немерле есть средства описания ссылок? Если нет, тогда это просто проявление эрудиции, а КОП это прост повод.
Любой язык подерживающий метапрограммирование позволяет легко делать то для чего ты хочешь использовать свой КОП. Поэтому непонятно зачем он нужен.
Здравствуйте, savinov, Вы писали:
S>Нет. Различия очевидны: S>
S>Прокси это ширма объекта. S>КОП это подход к созданию виртуальной системы доступа к объектам. S>S>Сравнение имеет ровно столько смысла, сколько например сравнение прокси и АОП.
Это демагогия. Какая разница, если прокси позволяет сделать то, что вы хотите сделать с помощью КОП.
И без всяких умных слов вроде "подход к созданию виртуальной системы доступа к объектам" .
)
S>Не хотелось бы, но приходится объяснять очевидные вещи, как например, разницу между языком и поддержкой на уровне платформы: S>
S> Прокси как ширма объекта, которая реализуется с помощью другого объекта. S> Реализация различных "приятностей" на уровне той или иной платформы, например, динамических и прозрачных прокси, удаленных методов, контекстов и др. механизмов. S>S>Язык это язык, а платформа это платформа.
А зачем нужна какая-то платформа если достаточно средств языка (+ библиотеки)?
Рантайм языка в каком-то смысле и есть платформа.
Или вам надо обязательно чтобы сразу все отказались от там .NET, Java и бегом на новую платформу?
АХ>>Автор топика знаком с концепцией умных указателей (здесь), которой уже сто лет в обед? АХ>>С помощью перегрузки оператора "->" в C++ можно как раз добиться желаемого эффекта дополнительных промежуточных действий (при этом естественно все это может быть вложенным). АХ>>Об этом уже давно писалось в соотв. литературе.
S>Добиться желаемого эффекта с помощью умных указателей (так же как и с помощью многочисленных других существующих средств) нельзя. Знакомство же с такими механизмами полезно, чтобы понять мотивацию, а также недостатки существующих механизмов.
Почему нельзя?
Приведите конкретный пример (а не словоблудие) чего нельзя сделать с помощью умных указателей и можно с помощью КОП.
АХ>>Про Nemerle я вообще молчу .
S>Вы хотите сказать, что Немерле есть средства описания ссылок? Если нет, тогда это просто проявление эрудиции, а КОП это прост повод.
Здравствуйте, savinov, Вы писали:
S>Ну значит метаклассы это неплохая вещь. Я уже отмечал, что элементы решения предлагаются в самых разных подходах. Вопрос тогда состоит в сравнении разных подходов, в частности, метаклассов и КОП. Если какой-то эксперт по метаклассам мог сказать что-то конкретное по этому поводу, было бы весьма интересно. (А я тем временем, попытаюсь сам разобраться.) Кстати, насколько я помню, метаклассы зародились еще до АОП, и были толчком к развитию АОП. Значит ли это, что в метаклассах нашли какие-то недостатки, которые попытались исправить в АОП?
Метаклассы -- понятие гораздо более широкое, чем то, которое вы называете AOP.
Я предпочитаю рассматривать AOP как subset MOPa, что во многом соответствует оригинальной идее АОП. Gregor Kiczales сделал попытку обобщить достаточно абстрактую теорию MOP в конкретную мэнстримовскую реализацию.
S>Вообше, по большому счету, КОП движется именно в этом большом направлении, где мы хотим создать для себя свою собственную среду, т.е. изменить законы функционирования программы и объектов внутри этой же самой прораммы. В КОП каждый объект это с одной стороны просто объект, а с другой это среда для других (внутренних) объектов.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, savinov, Вы писали:
S>>Другие примеры: S>>Диагности при доступе к объектам из одного места (логи). S>>Транзакции (открыть при доступе, закрыть при выходе). S>>Персистенс (загрузить при доступе, сбросить обратно при выходе). S>>Удаленность (переслать запрос на др. комп и вернуть результат). S>>Собственный контейнер для объектов с нужными функциями поддержки жизни. S>>... (список бесконечен)
S>>Во всех этих случах все эти промежуточные функции принципиально отделены от целевых методов, но описывюатся в самой программе. Оригинальность в том, что мы моделируем ссылки и их функции.
S>>Ну как, впечатляет?
FR>Если знаком с метапрограммированием (и тем более с его помощью уже реализовывал подобные вещи) то не впечатляет.
Да и не обязательно с метапрограммированием. Все это уже 100 раз реализовано(хотя бы у Фаулера )
Если же говорить о красоте решения, то тут можно рассмотреть АОП как паттерн, а метапрограммирование (будь то немерле или еще что) -- как средство для реализации этого паттерна.
Так что и КОП -- это скорее всего паттерн в данном контексте.
АХ>Приведите конкретный пример (а не словоблудие) чего нельзя сделать с помощью умных указателей и можно с помощью КОП.
Было бы хорошо, но тогда я бы всю жизнь придумывал примеры, поскольку таких средств реализации как умные указатели очень много. Т.е. надо выбирать: либо двигаться вперед, либо смотреть назад. Потом Вы мне предложите показать сравнение с реализацией на ассемблере, на Прологе на паттернах ГОФ. Я бы это с радостью сделал, но Вам это не поможет понять подход: только Вы сами можете себя убедить в чем-то. Так что дерзайте, если желаете, а если нет, так не надо искать искусственные причины типа это все давно известно.
Но я удовольствием отвечу на вопросы по существу КОП.
АХ>>>Про Nemerle я вообще молчу .
S>>Вы хотите сказать, что Немерле есть средства описания ссылок? Если нет, тогда это просто проявление эрудиции, а КОП это прост повод.
АХ>Здесь уже приводили пример: АХ>Re[9]: Концептно-ориентированное прораммирование (КОП)
Я не увидел там нужной логики вообще и ссылок в частности.
Насколько я понял, там реализуется следующая логика:
объект хранит идентификатор.
для доступа к объекту определяется стандартный интерфейс с методом, который по id возвращает ссылку
метод реализуется в центральном пункте доступа, где собственно решается, откуда его вынуть
Это стандартный (в чем-то наивный) подход, который имеет мало отношения к теме КОП. Вот его принципиальные недостатки:
Объект хранит свой идентификатор. Это не просто недостаток — это приговор. Пример, как делать не надо (антипаттерн). Средства идентификации и доступа нельзя совмещать с основной бизнес-логикой. Но в ООП обычно другого выхода нет.
В программе мы получаем ссылку на объект путем разрешения идентификатора. Это тоже антипаттерн, причем имеющий фундаментальное значение. Получать разрешенную ссылку нельзя. Это очень небезопасно. По той же причине, почему агенты спец.служб используют клички, а по записи в БД вы никогда не получите адрес в памяти. Такой подход работает только в игрушечных системах.
Так и не определен нужный формат ссылки.
Мы не можем просто применить метод к идентификатору и получить результат.
Вам понятны эти аргументы? Если нет, тогда задайте конкретный вопрос.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, savinov, Вы писали:
S>>Нет. Различия очевидны: S>>
S>>Прокси это ширма объекта. S>>КОП это подход к созданию виртуальной системы доступа к объектам. S>>S>>Сравнение имеет ровно столько смысла, сколько например сравнение прокси и АОП. АХ>Это демагогия. Какая разница, если прокси позволяет сделать то, что вы хотите сделать с помощью КОП. АХ>И без всяких умных слов вроде "подход к созданию виртуальной системы доступа к объектам" .
Демагонией как раз Вы занимаетесь, поскольку приводите аргументы типа "подход А не нужен, поскльку его можно реализовать с помощью средства Б". Очевидно, что это демагония. Следуя этому правилу поддержка виртуальных методов вовсе не нужна, поскольку все это уже существовало давным давно, например, берешь таблицу указателей на функции и все. Реляционная модель данных тоже не нужна, поскольку все нужное можно реализовать самому. Ну и т.д.
АХ>Или вам надо обязательно чтобы сразу все отказались от там .NET, Java и бегом на новую платформу?
Нет, мне вообще ничего не надо, а уж тем более, чтобы кто-то куда-то переходил. Я думаю, Вы не о том думаете.
АХ>>>Автор топика знаком с концепцией умных указателей (здесь), которой уже сто лет в обед? АХ>>>С помощью перегрузки оператора "->" в C++ можно как раз добиться желаемого эффекта дополнительных промежуточных действий (при этом естественно все это может быть вложенным). АХ>>>Об этом уже давно писалось в соотв. литературе.
S>>Добиться желаемого эффекта с помощью умных указателей (так же как и с помощью многочисленных других существующих средств) нельзя. Знакомство же с такими механизмами полезно, чтобы понять мотивацию, а также недостатки существующих механизмов.
АХ>Почему нельзя?
Из-за высокой сложности и весьма ограниченных возможностей. Например, где здесь механизм (иерархического) разрешения ссылок? Где здесь сложные ссылки, состоящие из нескольких сегментов (типа почтового адреса)? Где здесь перехват нужных методов и неперехват ненужных? Где здесь двойственные методы? И еще много других "где" и "как". Умные указатели это приспособа, которая без самой себя, без реализации с помощью шаблонов не существует. А КОП это набор принципов, а уже потом их реализация. На КОП можно программировать и без КО языка.
Я допускаю, что что-то можно сделать умными ссылками и добиться определенного эффекта, но какой ценой.
Здравствуйте, savinov, Вы писали:
S>Это ключевой вопрос. Для понимания КОП нужно понять, что такое ссылка и для чего она нужна.
Я это прекрасно понимаю. Давай дальше.
S> Ну а разновидности прокси это всего лишь один из паттернов, наравне с многими другими языковыми и неязыковыми средствами, которые можно как-то приспособить для решения этой задачи.
Не знаю что ты хотел сказать словом приспособить. Я бы употребил глагол использовать.
S> Так что сравнивать КОП с ними не имеет большого смысла.
КОП это нечто несуществующее. Я же предлагаю тебе существующее решение, которое все что ты перечислил решает.
S> Это все равно, что сравнивать принципы архитектуры с лопатой.
Негодное сравнение.
S>Я тебя не подозреваю, а просто говорю, что твои познания имеют довольно далекое отношения к предмету обсуждения.
Малчык, ты бы заканчивал рассуждать о моих познаниях, а то, сдается мне, если занеяться пенисометрией, то результаты измерений окажутся далеко не в твою пользу.
S> У тебя есть один аргумент: это можно реализовать так-то.
А у тебя их вобще нет.
S>Другой пример, использование CORBA. Если хочется что-то свое, то легко можно написать свой moddleware для удаленных объектов.
Можно. Ты это к чему привел?
S> Но ведь это все как раз то, чего нам НЕ нужно, т.е. с чем мы боремся.
А с чем вы боретесь?
S>И пока ты это не воспримешь, то извини, но я не могу сказать, что ты понял хотя бы цели КОП.
Ну ну.
S> Цель КОП состоит в описании ссылок и их функций наравне с объектами, которые они представляют.
Абалдеть. Ну описали мы их. Дальше что? Пока что ты описываешь исключительно шашечки. Ехать куда?
AVK>>В случае .NET это свойство рантайма. Это еще глубже, чем свойство языка.
S>Правильно, т.е. как раз то, что нам НЕ нужно.
А что вам нужно?
S> КОП направлен на создание своего собственного рантайма,
Сильно. Дальше можно не продолжать.
S>Просто попытайся понять цели КОП как они есть
Чтобы эти цели понять, их бы надо привести. А пока что ты приводишь не цели, а какое то обрывочное собственное видение.
Итак, цели могут быть:
1) Ускорение разработки
2) Улучшение качества кода
4) Улучшение масштабируемости
5) Улучшение командной разработки
6) Увеличение читаемости кода
И так далее. А как только ты с целями определишься, будь добр, проведи анализ, каким образом КОП помогает этих целей достич и в чем преимущество по сравнению с существующими решениями. Пока ты этого не сделаешь, все твои теории не стоят денег, потраченных на трафик для их передачи.
S>, а не исходя из существующих способов реализации систем, т.е. не проецируй идею на то, что уже известно.
А ты уверен, что ты придумал что то новое?
AVK>>Замени контекст на контейнер и получишь то же самое, что ты тут пишешь. Только, в отличие от твоих вариантов, эта механика значительно гибче и позволяет сделать больше.
S>Ты описываешь свойства платформы, а я говорю о свойствах языка.
Ну и что?
S> Ты говоришь о способах реализации, а я говорю о целях реализации. Ты говоришь о механизмах, а я говорю о принципах проектирования. Вывод: мы говорим на разных языках.
Вывод — ты сам плохо представляешь, о чем ты говоришь. Иначе я не могу предположить, почему ты не можешь внятно ответить ни на один заданный в этом топике вопрос.
S>Попытаюсь еще раз объяснить. КОП основан на описании ссылок и их функций.
Здорово. Едем дальше.
S> Я их не вижу в ДотНет (хотя ДотНет это не язык а платформа).
Ты же только что рассуждал, что ты говоришь об архитектурных принципах, т.е. о высоком. А теперь рассказываешь о том, что в платформе нет этого самого высокого. Нестыковочка выходит. Так вот, твоя идея реализуется на базе того, что в дотнете уже существует. Идея остается идеей, физическая реализация реализацией. Understand?
S> Покажи мне какой язык позволяет моделировать ссылки и тогда можно будет что-то обсуждать.
Любой нормальный язык на платформе .NET.
S> Нет ссылок — нет КОП, а есть ООП.
А КОП уже противопоставляется ООП?
AVK>>Возможности абстракций не безграничны. Абстрагироваться можно от более менее сопоставимых вещей. Когда же параметры среды отличаются на несколько порядков, абстракция ни к чему хорошему не приведет.
S>Я вижу ты мыслишь с точки зрения подрядчика.
Это плохо?
S> Я не предлагаю ничего реализовать.
Тогда нафига ты нужен?
S>Речь идет о принципах программирования, т.е. о принципах написания программы.
А ехать?
S> Можно мыслить программу в терминах объектов как учит ООП (опять же не говори о проблемах виртуальных функций или множественном наследовании). Ну а КОП предлагает мыслить программу в терминах ссылок и объектов.
Помыслили. Ехать куда?
S>Я сразу скажу — справится. Но при этом добавлю: это также можно реализовать и другими способами. Извини, но твои аргументы "против" стандартны
Это плохо?
S>С ними спорить глупо и бесполезно,
Да, с фактами спорить действительно глупо и бесполезно. Но пытаться придумать бесполезную вещь еще более глупо и бесполезно. По определению.
S> поскольку так оно и есть. Ну например, по твоему ООП не было нужно,
Это оно по твоему не нужно. А по моему очень даже.
S> поскольку я и так могу на Си реализовать все это,
Совершенно верно, можно.
S> причем быстрее и надежнее,
А это абсолютно не так. ООП, буде поддержана языком и рантаймом, становится реализуемой на порядок проще и надежнее. Это факт. Вот точно таких же фактов от тебя ожидают все в этом форуме.
S>По твоему это аргумент против ООП, а по моему это вообще не имеет отношения к делу.
И давай не будем заниматься демагогией, т.е. приписывать мне то, чего я никогда не говорил, а потом, на основании этого, делать выводы о глубине моих заблуждений.
S> Так что решай сам, будем ли мы обсуждать принципы программирования или возможность что-то реализовать помощью тех или иных платформ или паттернов.
Мы будем обсуждать что угодно, если ты потрудишься обосновать смысл своих предложений.
S>Могу только повторить: укажи мне на подход, где бы могли бы описать свою собственную виртуальную систему обозначений объектов и доступа к ним.
Пример. На любом доступном тебе языке или псевдокоде.
S> Если такой нет, то значит КОП как минимум оригинален.
Понимаешь, придумать что либо оригинальное не сложно. Хочешь докажу?
Итак, новая секретная разработка наших ученых — Сексуально Ориентированное Программирование. Сокращенно СОП.
В отличие от устаревшего ООП, СОП предполагает вместо объектов использовать субъекты. Субъекты бывают двух базовых типов — man и women. Между собой они взаимодействуют посредством связей — links. Политика образования связей формируется специальной сущностью, называемой behavior. Совокупность субъектов, объединенных связями называетс community. Программа представляет из себя структуру, состоящую из фрактально (возможно иерархически) сформированных community.
Ну как, на дисер тянет?
Кстати, тест на твои собственные познания в теории языков, коль скороты взялся оценивать мои. То, что я описал, на самом деле всего лишь частный случай одной из существующих парадигм. Догадаешься какой?
S> Тогда далее стоит вопрос зачем это нужно и полезно ли это.
Он не далее стоит, он стоит в самом начале.
S> Здесь формальных доказательств быть не может.
А раз не может быть формальных доказательств, значит их не может быть вовсе? Так что ли?
S> Но главный аргумент состоит в том, что ссылки являются такими же полноценными элементами программы как и объекты,
Они и так являются. Даже в ООП. А в .NET, хуже того, ссылка это примитив рантайма. А для кастомизации этих самых ссылок как раз и служит TP. Только, видишь ли в чем проблема, применимость у этой кастомизации на практике оказалась весьма невелика.
Здравствуйте, savinov, Вы писали:
S>Демагонией как раз Вы занимаетесь, поскольку приводите аргументы типа "подход А не нужен, поскльку его можно реализовать с помощью средства Б". Очевидно, что это демагония.
Очевидно нет. Если с помощью А можно реализовать идею столь же эффективно, сколь с помощью нового подхода, то новый подход не нужен. По моему это очевидно. Не потрудитесь ли обосновать, в чем здесь демагогия.
S> Следуя этому правилу поддержка виртуальных методов вовсе не нужна, поскольку все это уже существовало давным давно, например, берешь таблицу указателей на функции и все.
Нет, не все. Это значительно сложнее и код получается менее качественным. Так что вперед, показывать, что КОП может выразить то или иное полезное решение лучше, чем любое из существующих средств.
S> Реляционная модель данных тоже не нужна, поскольку все нужное можно реализовать самому. Ну и т.д.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, savinov, Вы писали:
S>>Демагонией как раз Вы занимаетесь, поскольку приводите аргументы типа "подход А не нужен, поскльку его можно реализовать с помощью средства Б". Очевидно, что это демагония.
AVK>Очевидно нет. Если с помощью А можно реализовать идею столь же эффективно, сколь с помощью нового подхода, то новый подход не нужен. По моему это очевидно. Не потрудитесь ли обосновать, в чем здесь демагогия.
Демагогия в отсутствии точных критериев оценки (эффективности и простоты). Слова "можно реализовать" или даже "можно реализовать лучше, проще и эффективнее" имеют весьма общий характер. И спорить в такими утверждениями нельзя. Например, Ява в 10 раз медленнее, чем С++, ну и что? Там существенно меньше возможностей, ну и что? Простота и красотва — вот единственный критерий, но он неформальный.
S>> Следуя этому правилу поддержка виртуальных методов вовсе не нужна, поскольку все это уже существовало давным давно, например, берешь таблицу указателей на функции и все.
AVK>Нет, не все. Это значительно сложнее и код получается менее качественным. Так что вперед, показывать, что КОП может выразить то или иное полезное решение лучше, чем любое из существующих средств.
Про виртуальные методы я как раз понимаю, но Вы никогда это не докажете человеку, который привык реализовывать все вручную, и тем более, если для этого есть библиотека, и уже подавно, если он сам этого не хочет.
S>> Реляционная модель данных тоже не нужна, поскольку все нужное можно реализовать самому. Ну и т.д.
AVK>А это уж точно демагогия. Объяснять почему?
Это как раз Ваша логика, которую я привел для иллюстрации демагогии. Я уже как-то опоминал, что проблема состоит в том, что один конкретный человек обычно имеет свою излюбленную область, где он действительно является экспертом. А далее он утверждает, что с помощью известных ему механизмов он сделает все лучше, чем с помощью альтернативных методов. И он будет прав. Если взять пример с реляционной моделью, то знаете скольким людям она действительно не нужна, причем совершенно обоснованно, поскольку они способны все сделать вручную гораздо быстрее и надежнее? На этом (и большинстве других) форумах обсуждение как раз и сводится к религиозным боям не на жизнь а на смерть, где главным аргументом является "я сам с помощью метода А сделаю все лучше, чем ты предлагаешь с помощью метода Б". Нет постановки проблемы, нет критериев эффективности, нет ничего, кроме желания показать, что ты самый крутой. Что касается меня, то я в таких спорах не участвую ввиду их бессмысленности (поскольку это демагогия).
Если Вы хотите дискуссии по существу, то задавайте вопросы по существу. Вопрос по существу отличается от пустого вопроса наличием хотя бы одного-двух терминов, специфичных для обсуждаемого вопроса. Вопсро типа "докажите мне, что это лучше" таких терминов не содержит. Кроме того, это претензия, а не вопрос. Так что я могу только еще раз попросить: задавайте вопросы по существу предлагаемого механизма. Если у Вас нет времени и/или желания вникать в детали, то просто не завайте вопросов и все.
.
