S>Да, действительно так. Питон оказывается может как хамелеон имитировать другой класс. Это заслуга Питона (но не ООП, очевидно). Не хочу тебя расстраивать, но это мало что меняет. Во-первых, ты по-прежнему должен работать с прокси, т.е. надо писать так: S>
>>>> proxy = Proxy( rgb )
>>>> proxy.Green()
S>
S>Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом? Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать S>
>>>> rgb = RGB( 100, 192, 240 )
>>>> rgb.Red()
S>
S>и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит, а потому нужно пригласить КОП, который это умеет делать.
С помощью метаклассов можно сделать что будет именно целевой объект, а прокси вклинится совершенно незаметно.
S>Следующая, более важная причина. В КОП во время выполнения поддерживается иерархия объектов, а потому т.н. прокси может иметь несколько внутренних объектов (в его области), для которых он выдал ссылки. В этом смысле этот промежуточный объект это граница пространства через которую проходят запросы и где выполняются промежуточные действия (типа паспортного контроля на границе). Отсутствие иерархии это в КОП частный случай, когда ссылки не используются и мы приходим к ООП.
Метаклассы это обычные классы, так что и иерархия и все остальное есть.
S>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы. Например, даже если мы напишем
А зачем их моделировать? Того же самого можно добится метаклассами в питоне, макросами в лиспе и немерле.
Здравствуйте, Sinclair, Вы писали:
E>>А что сейчас для защиты в области информатики внедрения уже не нужны? S>Это для к.т.н. нужны. А если к.ф-м.н — то достаточно "уникального вклада в науку".
Теперь понятно, почему реализация КОП может все сделать только хуже -- тогда ведь такая стройная теория накроется. Короче, "вся библия нафиг" ((С) Оба-на).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, savinov, Вы писали:
AL>>Здравствуйте, savinov, Вы писали:
S>Вот здесь я не понял. Дело в том, что объекты не могут в принципе изменить своего положения. Ссылка дается раз и навсегда при рождении и до смерти. А ссылка это и есть положение объекта (его адрес во внутренней структуре пространств). Соответственно, менять процедуру доступа во время выполнения не надо -- она известна во время компиляции.
Если делать предположение, что взаимное положение известно во время компиляции, то никакого jit-а примитивов координационного слоя в рантайме не требуется. Поскольку сами примитивы там становятся ненужными. Только это как-то неинтересно
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, savinov, Вы писали:
AL>>>Здравствуйте, savinov, Вы писали:
S>>Вот здесь я не понял. Дело в том, что объекты не могут в принципе изменить своего положения. Ссылка дается раз и навсегда при рождении и до смерти. А ссылка это и есть положение объекта (его адрес во внутренней структуре пространств). Соответственно, менять процедуру доступа во время выполнения не надо -- она известна во время компиляции.
AL>Если делать предположение, что взаимное положение известно во время компиляции, то никакого jit-а примитивов координационного слоя в рантайме не требуется. Поскольку сами примитивы там становятся ненужными. Только это как-то неинтересно
Да, это менее интересно, но ведь есть много других интересных проблем. Кроме того, произвольный (неизвестный во время компиляци) формат ссылки (=структура адреса, =расположение объекта) встречается в любом более или менее сложном приложении, например, при реализации БД. Язык позволяет автоматизировать только простые вещи, а в общем случае работу с ссылками надо реализовывать самому. Например, представим, что объекты хранятся в иерархическом контейнере, каждый локальный адрес это целое число. Тогда полная ссылка это последовательность целвых чисел. Но автоматизировать работу с такими ссылками языковыми средствами нельзя (сложно), а потому надо реализовать поддержку во время выполнения. Я думаю, что эта тема относится к анализу и дизайну систем. Вообще, я считаю, что вопрос представления и доступа является первичным при дизайне системы, т.е. надо определить где будут жить объекты, какие границы пересекаются при доступа, как они обозначаются и т.п. Ну а в языках дается поддержка только базовых средства.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, savinov, Вы писали:
S>>Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом? S>Если хочешь — работай. Хочешь через прокси — работай через прокси. Или ты хочешь заставить себя работать с прокси даже тогда, когда хочешь работать с конечным объектом?
Нет, конечно. Я вовсе не против прокси. Я просто хочу подчеркнуть принципиальную разницу между двумя подходами к организации опосредования: традициооные прокси (замещающие объекты), и
КОП
Есть и другие средства, например, можно использовать АОП, и там будут свои свойства. Их просто понимать и использовать по назначению.
S>>Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать S>>
S>>и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит S>Подсказка: никто не мешает запроксировать сам вызов RGB, который вернет то, что нужно. Точнее, мешает, но об этом далее.
S>>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы. Например, даже если мы напишем S>>
S>>то все равно наша ссылка это обычная системная ссылка. S>Ну и что?
Если это системная ссылка, то отсюда все ограничения стандартных ссылок, которые предоставляются средой и не контролируются. Недостатки см. ниже.
S>>Подумай о том, что этот объект может быть не в системной куче, а где-нибудь в трудно доступном месте, куда даже лучшая зубная щетка не достает. Че тогда будешь делать? S>То же самое. Вот, в дотнете поддерживается прозрачное проксирование объектов через границу доменов. Никаких проблем — все достает. Статическая типизация ограничивает удобство написания универсальных прокси; для питона это не проблема.
Возможно (я не знаком с этим). Я как раз утверждаю, что многие средства опосредованного доступа реализованы в том или ином виде в разных языках или платформах. Но проблема состоит в том, что хочется разработать теоретически правильные средства, основанные на базовых принципах и далее реализованные в каких-то специальных языковых конструкциях. Я привел критерии такого механизма и предложил решение. Конечно, есть пересечения с тем, что уже сделано. Например, мало кто знает, но в С++ есть старый метод, с помощью которого можно реализовать свой формат ссылок с помощью шаблонов. Весьма интересный и полезный метод. Но ведь это даже не паттерн, а просто трюк! А нам хочется иметь красивый, простой, естественный и общий подход. Кроме того, есть множество библиотек или платформ, предоставляющих толстые ссылки для своих объектов и средства опосредования, но ведь это тоже средства заточенные для решения определенных задач. А нам хочется иметь возможность построить в своей программе свою систему координат, свою средства обозначения объектов (своя почта).
S>>Методов на самом деле кучу, но просто все это надо будет делать руками. Но хуже всего то, что это сразу приводит к размножению кода. Например, пусть у меня объекты хранятся на разных компах. Тогда нужна ссылка: S>>
S>>reference {
S>> String compName;
S>> int port;
S>> int objectId;
S>>}
S>>
S>>А далее я хочу все свои имеющиеся и будущие классы представлять такими ссылками, но пользоваться ими как обычными объектами, например: S>>
S>> Customer cust = new Customer();
S>> Account acc = new Account(cust);
S>> double acc.setBalance(1000);
S>>}
S>>
S>>Здесь все ссылки имеют сложный формат из трех полей. S>Пардон, а откуда берутся значения этих полей? Злая магия подставляет имя компьютера и порт? S>>Но используются объекты как обычно. Если в будущем изменится формат ссылок, способ хранения объектов или что-то еще в механизме доступа, то этот код останется таким же. Круто?
S>А особенно круто — то, что это уже есть и доступно. В 100% сред это доступно при отказе от использования оператора new в прикладном коде — вместо этого используются вызовы фабрик, которые в свою очередь проксируются в одном месте.
Мне таких решений не известно. Я думаю, что это либо платформы, либо какие-то элементы решения. Наличие таких частичных решений лишь подчеркивает актуальность задачи. А в КОП предлагается простое и принципиальное решение на уровне языка програмирования.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, savinov, Вы писали:
S>>Да, действительно так. Питон оказывается может как хамелеон имитировать другой класс. Это заслуга Питона (но не ООП, очевидно). Не хочу тебя расстраивать, но это мало что меняет. Во-первых, ты по-прежнему должен работать с прокси, т.е. надо писать так: S>>
S>>Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом? Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать S>>
S>>и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит, а потому нужно пригласить КОП, который это умеет делать.
FR>С помощью метаклассов можно сделать что будет именно целевой объект, а прокси вклинится совершенно незаметно.
S>>Следующая, более важная причина. В КОП во время выполнения поддерживается иерархия объектов, а потому т.н. прокси может иметь несколько внутренних объектов (в его области), для которых он выдал ссылки. В этом смысле этот промежуточный объект это граница пространства через которую проходят запросы и где выполняются промежуточные действия (типа паспортного контроля на границе). Отсутствие иерархии это в КОП частный случай, когда ссылки не используются и мы приходим к ООП.
FR>Метаклассы это обычные классы, так что и иерархия и все остальное есть.
S>>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы. Например, даже если мы напишем
FR>А зачем их моделировать? Того же самого можно добится метаклассами в питоне, макросами в лиспе и немерле.
Ну значит метаклассы это неплохая вещь. Я уже отмечал, что элементы решения предлагаются в самых разных подходах. Вопрос тогда состоит в сравнении разных подходов, в частности, метаклассов и КОП. Если какой-то эксперт по метаклассам мог сказать что-то конкретное по этому поводу, было бы весьма интересно. (А я тем временем, попытаюсь сам разобраться.) Кстати, насколько я помню, метаклассы зародились еще до АОП, и были толчком к развитию АОП. Значит ли это, что в метаклассах нашли какие-то недостатки, которые попытались исправить в АОП? Вообше, по большому счету, КОП движется именно в этом большом направлении, где мы хотим создать для себя свою собственную среду, т.е. изменить законы функционирования программы и объектов внутри этой же самой прораммы. В КОП каждый объект это с одной стороны просто объект, а с другой это среда для других (внутренних) объектов.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Sinclair, Вы писали:
E>>>А что сейчас для защиты в области информатики внедрения уже не нужны? S>>Это для к.т.н. нужны. А если к.ф-м.н — то достаточно "уникального вклада в науку".
E>Теперь понятно, почему реализация КОП может все сделать только хуже -- тогда ведь такая стройная теория накроется. Короче, "вся библия нафиг" ((С) Оба-на).
E>)
Совершенно верно. Но это касается любой теории. Когда надо ее реализовать, то красота и изящность пропадает. Правда появляются другие радости, например, возможность что-то подрогать.
В любом случае, цель КОП не является прагматический. Это просто свободное творчество, за которое никто не платит (к сожалению). Соответственно, времени на реализацию нет. А погружаться в кучу реальных проблем, когда есть множество более интересных задач в области дизайна КО языка или КО базы данных охоты нет.
Здравствуйте, savinov, Вы писали:
E>>Теперь понятно, почему реализация КОП может все сделать только хуже -- тогда ведь такая стройная теория накроется. Короче, "вся библия нафиг" ((С) Оба-на).
E>>)
S>Совершенно верно. Но это касается любой теории. Когда надо ее реализовать, то красота и изящность пропадает. Правда появляются другие радости, например, возможность что-то подрогать.
S>В любом случае, цель КОП не является прагматический. Это просто свободное творчество, за которое никто не платит (к сожалению). Соответственно, времени на реализацию нет. А погружаться в кучу реальных проблем, когда есть множество более интересных задач в области дизайна КО языка или КО базы данных охоты нет.
По простому это называется пудрить людям мозги.
Хотя, имхо, в области образования предпочитают другой термин: заниматься наукой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, savinov, Вы писали:
E>>>Теперь понятно, почему реализация КОП может все сделать только хуже -- тогда ведь такая стройная теория накроется. Короче, "вся библия нафиг" ((С) Оба-на).
E>>>)
S>>Совершенно верно. Но это касается любой теории. Когда надо ее реализовать, то красота и изящность пропадает. Правда появляются другие радости, например, возможность что-то подрогать.
S>>В любом случае, цель КОП не является прагматический. Это просто свободное творчество, за которое никто не платит (к сожалению). Соответственно, времени на реализацию нет. А погружаться в кучу реальных проблем, когда есть множество более интересных задач в области дизайна КО языка или КО базы данных охоты нет.
E>По простому это называется пудрить людям мозги. E>Хотя, имхо, в области образования предпочитают другой термин: заниматься наукой.
Ну можно и так сказать. Но только давай будем честными до конца: тов. GoF тоже пудрит людям мозги (пример случайный). Таким образом, важно не то, что пудрят мозги или нет, а является ли это полезным в конце концов.
Здравствуйте, savinov, Вы писали:
E>>По простому это называется пудрить людям мозги. E>>Хотя, имхо, в области образования предпочитают другой термин: заниматься наукой.
S>Ну можно и так сказать. Но только давай будем честными до конца: тов. GoF тоже пудрит людям мозги (пример случайный). Таким образом, важно не то, что пудрят мозги или нет, а является ли это полезным в конце концов.
Ну и какая полезность в предлагаемой вами КОП? Не для вас (для вас это научная работа), а для, например, читателей RSDN?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
S>Да, действительно так. Питон оказывается может как хамелеон имитировать другой класс. Это заслуга Питона (но не ООП, очевидно).
ООП об этом хамелеонстве ничего не говорит. Более того, если мы говорим о чистом ООП, то погляди в Smalltalk, где те же самые методы применяются еще более часто, чем в Питоне.
Не хочу тебя расстраивать, но это мало что меняет. Во-первых, ты по-прежнему должен работать с прокси, т.е. надо писать так: S>
>>>> proxy = Proxy( rgb )
>>>> proxy.Green()
S>
S>Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом? Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать S>
>>>> rgb = RGB( 100, 192, 240 )
>>>> rgb.Red()
S>
S>и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит, а потому нужно пригласить КОП, который это умеет делать.
rgb = RGB( 100, 192, 240 )
а будет подставляться прокси.
S>Следующая, более важная причина. В КОП во время выполнения поддерживается иерархия объектов, а потому т.н. прокси может иметь несколько внутренних объектов (в его области), для которых он выдал ссылки. В этом смысле этот промежуточный объект это граница пространства через которую проходят запросы и где выполняются промежуточные действия (типа паспортного контроля на границе). Отсутствие иерархии это в КОП частный случай, когда ссылки не используются и мы приходим к ООП.
Че, на те объекты тоже нужны прокси? Или автоматический проксификатор? Ну сделай, правда это чуточку посложнее будет. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496741
S>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы.
Да можно. Переименуй мой класс Proxy в класс Concept, добавь ему необходимые тебе методы, и будет тебе счастье!
Например, даже если мы напишем S>
>>>> proxy = Proxy( rgb )
>>>> proxy.Green()
S>
S>то все равно наша ссылка это обычная системная ссылка.
Ну да, потому что процессор это обычный системный процессор. Значит системная ссылка обязательно где-то будет! Ну и по логике вещей она будет указывать на этот прокси, который будет проверять границы так, как тебе нужно. Все это можно реализовать в любом языке с интроспекцией, даже в Java и C#. Просто на питоне эти действия будут более простыми, поскольку он ближе к чистому ООП. SmallTalk еще ближе, там это делается еще проще.
Подумай о том, что этот объект может быть не в системной куче, а где-нибудь в трудно доступном месте, куда даже лучшая зубная щетка не достает.
Ну да, прокси должен доставать объект откуда надо. Например, между машинами, как в CORBA и DCOM.
Для питона есть, например, такое: http://pyro.sourceforge.net/ (это аналог Java RMI)
Но есть еще и такое: http://pybuild.sourceforge.net/pyinvoke.html
В итоге ты абсолютно прозрачно работаешь с объектами, а они на самом деле могут быть на другой машине.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, savinov, Вы писали:
E>>>По простому это называется пудрить людям мозги. E>>>Хотя, имхо, в области образования предпочитают другой термин: заниматься наукой.
S>>Ну можно и так сказать. Но только давай будем честными до конца: тов. GoF тоже пудрит людям мозги (пример случайный). Таким образом, важно не то, что пудрят мозги или нет, а является ли это полезным в конце концов.
E>Ну и какая полезность в предлагаемой вами КОП? Не для вас (для вас это научная работа), а для, например, читателей RSDN?
Полезность мы вряд ли сможем определить -- это может сделать только время.
Для меня это вовсе не научная работа (иначе это было бы довольно бесполезно). Я уже упомянул, что это что-то вроде свободного творчества, хобби. Именно из-за отсутствия заказчика (который есть также в науке), можно сделать все правильно, а не так как требуется для отчета, для оппонента или др. типа заказчика. Именно по этой причине мне не надо это продвигать или пропагандировать (я делаю это для себя самого). Так что ситуация как в open source: нравится — пользуйся, а не нравится — не ешь. Наличие публикаций это всего лишь мотивация что-то закончить, т.е. подвести черту и завершить этап — иначе процесс продолжается до бесконечности. Примерно как наличие версий и этапов при разработке ПО. Ни для чего другого (к счастью) они мне не нужны.
savinov wrote: > Полезность мы вряд ли сможем определить -- это может сделать только время. > Для меня это вовсе не научная работа (иначе это было бы довольно > бесполезно). Я уже упомянул, что это что-то вроде свободного творчества, > хобби.
Тогда это называется "графоманство".
Здравствуйте, buriy, Вы писали:
S>>Да, действительно так. Питон оказывается может как хамелеон имитировать другой класс. Это заслуга Питона (но не ООП, очевидно). B>ООП об этом хамелеонстве ничего не говорит. Более того, если мы говорим о чистом ООП, то погляди в Smalltalk, где те же самые методы применяются еще более часто, чем в Питоне. B>Не хочу тебя расстраивать, но это мало что меняет. Во-первых, ты по-прежнему должен работать с прокси, т.е. надо писать так: S>>
S>>Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом? Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать S>>
S>>и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит, а потому нужно пригласить КОП, который это умеет делать.
B>Ну сделай
B>Тогда потом можно спокойно использовать
B>rgb = RGB( 100, 192, 240 ) B>а будет подставляться прокси.
Верю. Но сколько для этого надо было написать кода! Отсюда ясно, что язык не предназначен для таких задач (хотя и может описать какие-то механизмы более или менее удобно). Это хороший пример реализации какого-то паттерна или приема без прямой языковой поддержки. Так можно было то же самое написать на ассемблере или Си, но это бы заняло еще больше строй кода.
S>>Следующая, более важная причина. В КОП во время выполнения поддерживается иерархия объектов, а потому т.н. прокси может иметь несколько внутренних объектов (в его области), для которых он выдал ссылки. В этом смысле этот промежуточный объект это граница пространства через которую проходят запросы и где выполняются промежуточные действия (типа паспортного контроля на границе). Отсутствие иерархии это в КОП частный случай, когда ссылки не используются и мы приходим к ООП.
B>Че, на те объекты тоже нужны прокси? Или автоматический проксификатор? Ну сделай, правда это чуточку посложнее будет. B>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496741
Немного сложнее это мягко сказано. Но идея в том, что проксификация часто имеет вложенный характер. Это уже вряд ли можно назвать прокси в чистом виде, но я и не применял этот термин, а говорил об опосредовании. Здесь ближе паттерн chain of responsibility (http://www.python.org/workshops/1997-10/proceedings/savikko.html). В КОП является принципом, что вызов метода это путь к цели, а не конечный шаг. Дело в том, что любой объект в общем случае является удаленным, поскольку представляется произвольной ссылкой. Чтобы его достичь, надо проделать путь, который проходит через объекты, представляющие границы пространств (где живут объекты). Каждый их этих промежуточных объектов опосредует доступ, т.е. вносит свой вклад в обработку запроса. И только в самом конце выполняется вызываемый метод. Если назвать эти промежуточные объекты прокси, тогда получаем вложенное проксирование. В КОП это делается за пару строк, поскольку не только встроено в язык, но заложены в принципы программирования. Создай структуру пространств ("прокси") и только потом помещай туда объекты. Обычный же подход говорит, что надо создать сперва объекты, а потом создавать для них посредников в виде прокси (хотя бы потому, что прокси без целевых объектов просто не могут быть созданы). Это принципиальное отличие, понимание которого необходимо (что первично, а что вторично).
S>>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы. B>Да можно. Переименуй мой класс Proxy в класс Concept, добавь ему необходимые тебе методы, и будет тебе счастье!
Есть ли в Питоне передача объектов по значению? Если как и в Яве нет, тогда и говорить не о чем, поскольку ссылка всегда передается только по значению. Ссылка не имеет своей собственно ссылки и это ее отличие от объекта. Но даже если есть передача объектов по значению, как в С++, то сделать из таких объектов ссылки весьма сложно. Нужно очень сильно постараться, чтобы прилепить такого горбатого к стенке. Например, в С++ можно использовать шаблоны и smart pointers.
B>Например, даже если мы напишем S>>
S>>то все равно наша ссылка это обычная системная ссылка. B>Ну да, потому что процессор это обычный системный процессор. Значит системная ссылка обязательно где-то будет! Ну и по логике вещей она будет указывать на этот прокси, который будет проверять границы так, как тебе нужно. Все это можно реализовать в любом языке с интроспекцией, даже в Java и C#. Просто на питоне эти действия будут более простыми, поскольку он ближе к чистому ООП. SmallTalk еще ближе, там это делается еще проще.
Ссылка может иметь любой формат и не должна быть объектом. Если ссылка является объектом, то это уже симулирование ссылки, что можно с большим или меньшим успехом сделать с помощью прокси. А я хочу иметь нормальные ссылки в моем собственном формате, а не объект, который ведет себя как ссылка. Объект это объект, а ссылка это ссылка. Это двойственные понятия и их функции в системе ортогональны (взаимно пересекаются). Например, я хочу определить свои толстые ссылки (но не прокси), чтобы далее их использовать как самые обычные системные ссылки. Зачем? Ну затем же, для чего Ява использует свой формат ссылок, а не адреса в памяти. Затем же, для чего ты используешь имена компов, а не их IP-адрес, затем же для чего ты используешь имя файла, а не его номер блока на диске. Я бы сказал, что все программирование сводится просто к разработке такой системы опосредвоаня. Это нужно, что отвязаться от реальности и добиться виртуальности. Виртуализация это другой популярный термин. Мы хотим работать в виртуальной системе координат, а быть привязаны к физической реальности. Например, зачем в процессорах ввели виртуальную адресацию? Ведь это только замедляет доступ, поскольку каждый раз процессор (менеджер памяти) должен пересчитывать где в физической памяти находится элемент. Правильно, для того, чтобы отвязаться от физической памяти, поскольку это придает гибкость. То же самое в программировании. КОП предназначено для разработки своей виртуальной системы обозначений к объектам и прозрачного доступа к ним. В отличие от других языков, где некоторые вещи также можно реализовать, это является первичной и главной целью этого подхода. Убедил?
B>Подумай о том, что этот объект может быть не в системной куче, а где-нибудь в трудно доступном месте, куда даже лучшая зубная щетка не достает. B>Ну да, прокси должен доставать объект откуда надо. Например, между машинами, как в CORBA и DCOM. B>Для питона есть, например, такое: http://pyro.sourceforge.net/ (это аналог Java RMI) B>Но есть еще и такое: http://pybuild.sourceforge.net/pyinvoke.html B>В итоге ты абсолютно прозрачно работаешь с объектами, а они на самом деле могут быть на другой машине.
Совершенно верно, но все-таки это как раз то, что мы хотим избежать! Это ведь не поддержка на уровне языка, а просто библиотека или какой-то специальный механизм, заточенный под определенный вид задача (в данном случае под удаленные объекты). Такая поддержка существует уже десятки лет в самых разных формах: на уровне ОС, middleware, библиотек и др. штуковин.
Наша цель состоит в том, чтобы предоставить универсальные средства на уровне языка программирования. Например, что мне делать, если меня не устраивает Pyro, RMI или CORBA? Ведь это универсальные средства, которые м.б. либо слишком сложными либо слишком простыми, либо слишком небезопасными либо вообще делать не то что нужно. Пусть я хочу, чтобы в удаленное ссылке было еще одно поле с какой-то инфой. В этом смысле КОП как раз и дает языковые средства для описания произвольной системы обозначений обозначений объектов в программе.
Здравствуйте, Cyberax, Вы писали:
C>savinov wrote: >> Полезность мы вряд ли сможем определить -- это может сделать только время. >> Для меня это вовсе не научная работа (иначе это было бы довольно >> бесполезно). Я уже упомянул, что это что-то вроде свободного творчества, >> хобби. C>Тогда это называется "графоманство".
Ну хорошо, я не против. Называйте это как хотите, мне это безразлично, и я меньше всего об этом думаю.
В общем, все свелось к обсуждению как это называется и не преследует ли автор каких-то корыстных целей. Это очевидно, защитная реакция организма, который боится, что его сейчас перепрограммируют или переведут в другую веру (естественная, кстати, реакция). Интересно, что все возможные варианты ответов на вопрос зачем это делается имеют негативную оценку. Если для науки, то плохо. Если не для науки, то тоже плохо. Если из-за денег, то еще хуже. Выберите вариант ответа, который вас устроит и я так и отвчу Ну, впрочем, это форум, и другого здесь не может быть...
Здравствуйте, savinov, Вы писали:
S>Верю. Но сколько для этого надо было написать кода! Отсюда ясно, что язык не предназначен для таких задач (хотя и может описать какие-то механизмы более или менее удобно). Это хороший пример реализации какого-то паттерна или приема без прямой языковой поддержки. Так можно было то же самое написать на ассемблере или Си, но это бы заняло еще больше строй кода.
При использовании код писать вообще не придется. На си это сделать вообще не получится, только если препроцессором.
S>>>Следующая, более важная причина. В КОП во время выполнения поддерживается иерархия объектов, а потому т.н. прокси может иметь несколько внутренних объектов (в его области), для которых он выдал ссылки. В этом смысле этот промежуточный объект это граница пространства через которую проходят запросы и где выполняются промежуточные действия (типа паспортного контроля на границе). Отсутствие иерархии это в КОП частный случай, когда ссылки не используются и мы приходим к ООП.
B>>Че, на те объекты тоже нужны прокси? Или автоматический проксификатор? Ну сделай, правда это чуточку посложнее будет. B>>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496741
S>Немного сложнее это мягко сказано. Но идея в том, что проксификация часто имеет вложенный характер. Это уже вряд ли можно назвать прокси в чистом виде, но я и не применял этот термин, а говорил об опосредовании. Здесь ближе паттерн chain of responsibility (http://www.python.org/workshops/1997-10/proceedings/savikko.html). В КОП является принципом, что вызов метода это путь к цели, а не конечный шаг. Дело в том, что любой объект в общем случае является удаленным, поскольку представляется произвольной ссылкой. Чтобы его достичь, надо проделать путь, который проходит через объекты, представляющие границы пространств (где живут объекты). Каждый их этих промежуточных объектов опосредует доступ, т.е. вносит свой вклад в обработку запроса. И только в самом конце выполняется вызываемый метод. Если назвать эти промежуточные объекты прокси, тогда получаем вложенное проксирование. В КОП это делается за пару строк, поскольку не только встроено в язык, но заложены в принципы программирования. Создай структуру пространств ("прокси") и только потом помещай туда объекты. Обычный же подход говорит, что надо создать сперва объекты, а потом создавать для них посредников в виде прокси (хотя бы потому, что прокси без целевых объектов просто не могут быть созданы). Это принципиальное отличие, понимание которого необходимо (что первично, а что вторично).
Сделать путь не проблема как и любой уровень вложености для прокси.
В общем я думаю твой КОП вполне реализуем на динамических и макросоподерживающих языках в виде библиотеки. И использование тоже будет в пару строк.
S>>>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы. B>>Да можно. Переименуй мой класс Proxy в класс Concept, добавь ему необходимые тебе методы, и будет тебе счастье!
S>Есть ли в Питоне передача объектов по значению? Если как и в Яве нет, тогда и говорить не о чем, поскольку ссылка всегда передается только по значению. Ссылка не имеет своей собственно ссылки и это ее отличие от объекта. Но даже если есть передача объектов по значению, как в С++, то сделать из таких объектов ссылки весьма сложно. Нужно очень сильно постараться, чтобы прилепить такого горбатого к стенке. Например, в С++ можно использовать шаблоны и smart pointers.
В питоне есть гораздо более мощные средства обобщения чем шаблоны и умные указатели.
S>Ссылка может иметь любой формат и не должна быть объектом. Если ссылка является объектом, то это уже симулирование ссылки, что можно с большим или меньшим успехом сделать с помощью прокси. А я хочу иметь нормальные ссылки в моем собственном формате, а не объект, который ведет себя как ссылка. Объект это объект, а ссылка это ссылка. Это двойственные понятия и их функции в системе ортогональны (взаимно пересекаются). Например, я хочу определить свои толстые ссылки (но не прокси), чтобы далее их использовать как самые обычные системные ссылки. Зачем? Ну затем же, для чего Ява использует свой формат ссылок, а не адреса в памяти. Затем же, для чего ты используешь имена компов, а не их IP-адрес, затем же для чего ты используешь имя файла, а не его номер блока на диске. Я бы сказал, что все программирование сводится просто к разработке такой системы опосредвоаня. Это нужно, что отвязаться от реальности и добиться виртуальности. Виртуализация это другой популярный термин. Мы хотим работать в виртуальной системе координат, а быть привязаны к физической реальности. Например, зачем в процессорах ввели виртуальную адресацию? Ведь это только замедляет доступ, поскольку каждый раз процессор (менеджер памяти) должен пересчитывать где в физической памяти находится элемент. Правильно, для того, чтобы отвязаться от физической памяти, поскольку это придает гибкость. То же самое в программировании. КОП предназначено для разработки своей виртуальной системы обозначений к объектам и прозрачного доступа к ним. В отличие от других языков, где некоторые вещи также можно реализовать, это является первичной и главной целью этого подхода. Убедил?
В питоне все является объектом. Так что сделать ссылку не объект не получится. Аналогии по моему очень натянутые. Вообще если бы ты показал хоть один пример как твой КОП помогает решить конкретную проблему или задачу было бы намного продуктивнее, а так пока чистая вода.
S>Совершенно верно, но все-таки это как раз то, что мы хотим избежать! Это ведь не поддержка на уровне языка, а просто библиотека или какой-то специальный механизм, заточенный под определенный вид задача (в данном случае под удаленные объекты). Такая поддержка существует уже десятки лет в самых разных формах: на уровне ОС, middleware, библиотек и др. штуковин.
S>Наша цель состоит в том, чтобы предоставить универсальные средства на уровне языка программирования. Например, что мне делать, если меня не устраивает Pyro, RMI или CORBA? Ведь это универсальные средства, которые м.б. либо слишком сложными либо слишком простыми, либо слишком небезопасными либо вообще делать не то что нужно. Пусть я хочу, чтобы в удаленное ссылке было еще одно поле с какой-то инфой. В этом смысле КОП как раз и дает языковые средства для описания произвольной системы обозначений обозначений объектов в программе.
Добавить поле в динамических языках без проблем. Вообще поищи про утиную типизацию и динамическое добавление методов, тут много на эту тему ругались, то есть обсуждали
Здравствуйте, savinov, Вы писали:
S>В общем, все свелось к обсуждению как это называется и не преследует ли автор каких-то корыстных целей. Это очевидно, защитная реакция организма, который боится, что его сейчас перепрограммируют или переведут в другую веру (естественная, кстати, реакция). Интересно, что все возможные варианты ответов на вопрос зачем это делается имеют негативную оценку. Если для науки, то плохо. Если не для науки, то тоже плохо. Если из-за денег, то еще хуже. Выберите вариант ответа, который вас устроит и я так и отвчу Ну, впрочем, это форум, и другого здесь не может быть...
Если бы ты показал конкретный пример использования или хотя бы примеры решения проблем а не воду, было бы совсем другое обсуждение
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, savinov, Вы писали:
S>>В общем, все свелось к обсуждению как это называется и не преследует ли автор каких-то корыстных целей. Это очевидно, защитная реакция организма, который боится, что его сейчас перепрограммируют или переведут в другую веру (естественная, кстати, реакция). Интересно, что все возможные варианты ответов на вопрос зачем это делается имеют негативную оценку. Если для науки, то плохо. Если не для науки, то тоже плохо. Если из-за денег, то еще хуже. Выберите вариант ответа, который вас устроит и я так и отвчу Ну, впрочем, это форум, и другого здесь не может быть...
FR>Если бы ты показал конкретный пример использования или хотя бы примеры решения проблем а не воду, было бы совсем другое обсуждение
Вот тогда как раз было бы уже нечего обсуждать — все и так было бы ясно. Но в целом я согласен конечно, что нужны хорошие примеры. Но поскльку дисер мне не нужен, деньги тоже на этом не заработаешь, то и заниматься рутиной (что и так очевидно) мне нет охоты. Поэтому если все это не совсем ясно, или совсем не ясно, то я вполне могу понять, но изменить ничего не могу. Кроме того, я уверен, что даже пары хороших примеров будет недостаточно, поскольку это связано с религиозными воззрениями граждан, которые так просто не изменить. Так что пусть будет как будет. Пусть КОП сам пробивает себе дорогу в жизнь
Здравствуйте, savinov, Вы писали:
FR>>Если бы ты показал конкретный пример использования или хотя бы примеры решения проблем а не воду, было бы совсем другое обсуждение
S>Вот тогда как раз было бы уже нечего обсуждать — все и так было бы ясно. Но в целом я согласен конечно, что нужны хорошие примеры. Но поскльку дисер мне не нужен, деньги тоже на этом не заработаешь, то и заниматься рутиной (что и так очевидно) мне нет охоты. Поэтому если все это не совсем ясно, или совсем не ясно, то я вполне могу понять, но изменить ничего не могу. Кроме того, я уверен, что даже пары хороших примеров будет недостаточно, поскольку это связано с религиозными воззрениями граждан, которые так просто не изменить. Так что пусть будет как будет. Пусть КОП сам пробивает себе дорогу в жизнь
На консилиуме ученых и военных...
Входит в кабинет секритарша и гворит:
— Тут к вам рвется какой-то товарищь... я его сдержать немогу, говоит что дело государственной важности...
— Ну, что же впустите.
— Здравствуйте! Я изобретатель! Дайте рассказать про свою идею.
— Ну, что же говорите, раз все равно ворвались.
— Значичь идея такова... Вражеские самалеты подетаютк к нашей границе и вдруг переворачиваются и падают. Здорово?!
— Здорово! И как же это все работеат?!
— Не, ну, вы же ученые? Вам и думать как реализовать. А мое дело идею предложить!!!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, savinov, Вы писали:
FR>>>Если бы ты показал конкретный пример использования или хотя бы примеры решения проблем а не воду, было бы совсем другое обсуждение
S>>Вот тогда как раз было бы уже нечего обсуждать — все и так было бы ясно. Но в целом я согласен конечно, что нужны хорошие примеры. Но поскльку дисер мне не нужен, деньги тоже на этом не заработаешь, то и заниматься рутиной (что и так очевидно) мне нет охоты. Поэтому если все это не совсем ясно, или совсем не ясно, то я вполне могу понять, но изменить ничего не могу. Кроме того, я уверен, что даже пары хороших примеров будет недостаточно, поскольку это связано с религиозными воззрениями граждан, которые так просто не изменить. Так что пусть будет как будет. Пусть КОП сам пробивает себе дорогу в жизнь
E>Имхо, уместно повторить здесь анекдот, расказанный VladD2
E>На консилиуме ученых и военных...
E>Входит в кабинет секритарша и гворит:
E>— Тут к вам рвется какой-то товарищь... я его сдержать немогу, говоит что дело государственной важности...
E>— Ну, что же впустите.
E>— Здравствуйте! Я изобретатель! Дайте рассказать про свою идею.
E>— Ну, что же говорите, раз все равно ворвались.
E>— Значичь идея такова... Вражеские самалеты подетаютк к нашей границе и вдруг переворачиваются и падают. Здорово?!
E>— Здорово! И как же это все работеат?!
E>— Не, ну, вы же ученые? Вам и думать как реализовать. А мое дело идею предложить!!!
А мне почему-то сразу вспоминаетя другая ситуация. Когда разрабатывался JBoss где-то на 2-ой или 3-ей версии, то постоянно вламывались какие-то товарици, стучали кулаком по столу и требовали предоставить подробную документацию. Мол так писать системы нельзя, нужна документация, а то пользователям трудно жить. Им вежливо (а иногда и не очень) пытались объяснить, мол, проект бесплатный. Хочешь, смотри в исходники, напряги мозги и реши проблему сам. А лучше будет, если ты вот сам возьмешь и напишешь документацию. Но это доходило очень плохо — есть сорт людей, которые делать ничего не хотят, и особенно бесплатно. Но главное, если такому дать доку, то он выдвинет новые причины, почему он не может использовать систему, т.е. это процесс бесконечный: не так надо было писать программу, ребята, а по-другому! Т.е. критиков всегда больше, и они всегда знают, почему что-то НЕ будет работать, но никогда не знают, а как собственно заставить это работать. Чтобы въехать, скажем в АОП, надо довольно много времени. Для среднего профессора это может занять год (для студента существенно меньше). Это другая парадигма, которая требует изменить взгляд на устройство программы, а потому быстро это не сделать. И жаловаться на трудные условия и объектывные причины здесь бесполезно.
):