SiAVoL,

> E>К-хе, К-хе (смущенное покашливание), я опять согласен. Но вот наткнулся на случай, когда и функциональность нужно было чуть-чуть расширить, и интерфейс для этого заменить, и совместимость сохранить.

> Как бы это было на C#. Создаем новую версию интерфейса. Старую оставляем для совместимости, но по сути вызов старых методов теперь сводится к работе через новый интерфейс.

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

Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.

Если потребовать "почкования" не только интерфейсов, но и промежуточных классов, подобных C, введя вместо них C2, то в итоге это сведется к каскадной замене I на I2 по всему коду, чего как раз и хочется избежать.

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это C#. Я говорил о C++. В C# было принято несколько другое решение, о том, что функции наследников скрывают не все функции базовых классов, и грабли будут в чуть более тонком случае, когда новая сигнатура окажется при разрешении перегрузки лучшим кандидатом, чем старая. Полагаю, ты подобный пример, будучи лучше знаком с C#, подберешь проще, чем я.
Павел, тебе не кажется, что это уже перебор? Мы обсуждаем совершенно кошмарный способ обойти проблемы совместимости на С++. Делается утверждение, что С#, с его убогими генериками, и рядом с такими способами не стоял, и потребует какого-то "каскадных замен по всему коду". Вот это — твои слова:

Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.

Тебе показали, что вот это твое желание не просто выполняется в C# (даже 1.1), а выполняется на раз-два. Но ты продолжаешь уже пять постингов рассказывать про какие-то мифические страшные грабли при наследовании интерфейсов. А теперь ты просишь меня изобрести эти грабли, потому что у тебя так и не получилось!

Так вот, Павел: нет этих граблей. Не-ту-ти! Все в порядке. Да, можно придумать искусственный случай, когда мы в унаследованном интерфейсе ввели новый метод, который случайно лучше подошел для вызовов, чем старый. Внимание, вопрос: зачем? Человек, проектирующий I2, может сделать такой шаг только намеренно. Потому что ему очень хорошо видно, от кого он наследуется. И вряд ли у интерфейса-наследника будет одноименный член с неразличимой сигнатурой, но другой семантикой. Ну вот был у нас класс IOrder. Был у него AddItem(IProduct product, float amount). Ок, отнаследовались мы от него и сделали IOrder2.AddItem(IDiscreteProduct product, int amount). Ок, старые клиенты, которые вызывали

OrderFactory.NewOrder().AddItem(TunaCans, 50)

Раньше этот вызов попадал в I1, а теперь попадет в I2. Ну так мы для того и ввели новый метод, чтобы старые клиенты более эффективно работать в случае дискретных продуктов! Если бы я этого не хотел, то я бы назвал метод по-другому.

Здравствуйте, Sinclair, Вы писали:

ПК>>Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.

S>1. Унаследовать I2 от I1 можно?

Да.

S>2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?

Да. Но чтоб это имело смысл, придется унаследовать и все классы D, через которые клиенты получают доступ к C, а также все классы E, через которые клиенты получают доступ к D и т.п. Именно этого хочется избежать.

S>Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?

Противоречия нет; есть масса работы, которую не хочется делать.

Пример:

interface I { ... };

class C {
public:
  I1& i();
};

class D {
public:
  C& c();
};

class E {
public:
  D& d();
};

Здравствуйте, eao197, Вы писали:

IT>>3. Guid поможет отцу маршрутизации

E>Не-а, тогда все сводится к первому случаю. Маршрутизатор может передать исполнителю запрос, используя идентификатор от клиента, но когда он получает от исполнителя ответ, то как определить, какому-именно клиенту нужно ответ отдать? Либо сопрягая guid с именем клиента (тогда тот же trx_id получается), либо сохраняя guid вместе с именем клиента в БД

Меня не покидает ощущение, что ты как-то всё сильно усложняешь

Здравствуйте, VladD2, Вы писали:

VD>>>Извини, а сам boost::bind не является модификацией языка?

E>>Языка -- нет. Стандартной библиотеки -- да.

VD>Нет? И я могу вот так за просто получить в С++ указатель на произвольный метод?

Дело в том, что
1) в C++ смысла от этого ноль -- ведь чтобы вызвать метод по указателю, нужно знать точную сигнатуру метода.
2) с помощь явных кастов в C++ можно привести указатель на один метод к указателю на другой метод. Только это нафиг не нужно.

VD>Странно. А ведь boost::bind это море очень не быстро компилируемого кода который использует уж совсем не кчемную функциональность языка вроде указателей на методы. И все это вмесо примитивной модификации языка.

Никчемность указателей на методы -- это собственное впечатление?
Лично мне они кажутся настолько же удобными, как и указатели на функии. И время от времени я ими пользуюсь.

VD>Мне не хочется в очередной раз писать трактат о функциональных типах. Кажется о них было сказано уже довольно много. Ну, да если ты действительно не понимашь всю глубину маразма этой ситуации, то скажи... и я попытаюсь описать ее более детально.

Опиши.

VD>>>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...

E>>Нет. Далеко не всегда.

VD>И когда нельзя?
VD>Раскрывай.

---

Use case 1: Async Completion Token (так же рассматривался здесь

Автор: eao197
Дата: 20.05.05

)

Пусть у нас есть некий сервер S и несколько клиентов C1,...,Cn, которые к этому серверу подключаются. Каждый клиент отсылает запросы на сервер и каждый запрос должен уникальным образом однозначно идентифицироваться. Для этого клиент вставляет в запрос свой trx_id. Если клиенты подключаются к S по разным портам, то проблемы со смешением trx_id от разных клиентов, вроде бы нет. Но, сервер S на самом деле может представлять из себя более сложную структуру из маршрутизаторов R1,...,Rm и конкретных исполнителей P1,...,Po. Причем несколько клиентов могут быть подключены к одному маршрутизатору, а один маршрутизатор может быть подключен к нескольким исполнителям. При этом исполнитель хочет, чтобы все запросы, приходящие с конкретного маршрутизатора, имели уникальные идентификаторы. Получается, что маршрутизатор, к которому подключено несколько клиентов, не может использовать trx_id клиентов для обращения к исполнителю. Поскольку trx_id у клиентов могут пересекаться. И здесь возможны следующие варианты:

1. В качестве trx_id используется последовательно возрастающий unsigned int (обычное решение при использовании РСУБД для хранения информации о запросах). Тогда маршрутизатор принимает от клиентов их trx_id(Ci), сохраняет их в БД и получает новый trx_id(Rj). Далее делает запрос к Pk. Когда маршрутизатор получает от Pk ответ с trx_id(Rj), он по БД восстанавливает trx_id(Ci) и узнает, какому клиенту нужно передать ответ. Получается, что маршрутизатор должен работать с СУБД всегда, даже если он выполняет не очень сложные вещи. Например, если маршрутизатор выступает в роли load-balancer-а или просто выполняет рутинные преобразования данных в запросах (например, преобразует величины из одной системы счисления в другую, или конвертирует одну валюту в другую). Если же нужно объединить в цепочку несколько маршрутизаторов (каждый из которых выполняет собственные преобразования), то тогда будут лишние расходы не только по администрированию БД (и обеспечению отказоустойчивости), но и потери производительности (т.к. каждый маршрутизатор будет что-то записывать в БД).

2. В качестве trx_id применяется какой-то черный ящик. Только отправляющая сторона знает, что из себя представляет trx_id и как его распарсить. Тогда маршрутизатор принимает от клиентов их trx_id(Ci) и генерирует свой trx_id(Rj) в который включает идентификатор клиента и исходный trx_id(Ci). Далее trx_id(Rj) идет исполнителю Pk, но исполнитель совершенно не в курсе того, что находится в trx_id(Rj). И ему это совершенно не нужно знать. Когда маршрутизатор получает от исполнителя ответ с trx_id(Rj), то маршрутизатор извлекает из trx_id(Rj) идентификатор клиента и исходный trx_id(Ci). После чего не составляет труда переслать ответ нужному клиенту с нужным идентификатором. В таком подходе не нужно использовать СУБД для фиксации промежуточных данных (соответственно, не нужно обеспечивать отказоустойчивость). И нет лишних накладных расходов на обращения к БД.


Лично мне второй подход нравится гораздо больше. Но возникает вопрос, как все же представлять trx_id? Будет ли это просто неинтерпритируемая последовательность байт, которая на C++ представляется либо std::string, либо std::vector<char>? Или ее можно структурировать?

Так вот мой подход к сериализации позволяет выделить общий базовый класс trx_id_t, от которого каждая сторона может сделать себе производный класс. Например, клиенты могут делать rnd_trx_id_t (который хранит уникальный unsigned int из БД), а маршрутизаторы -- router_trx_id_t (который хранит идентификатор клиента и trx_id, полученный от клиента). При этом фишка в том, что маршрутизатору совершенно не нужно знать про тип rnd_trx_id_t и иметь его код на своей стороне. Когда Rj получает запрос от Ci, он десериализует только ту часть trx_id, которая известна обоим сторонам (т.е. базовый класс trx_id_t). Но когда десериализованный объект на стороне Rj сериализуется вновь, то получается точно такой же образ, какой был после сериализации на стороне Ci. Достигается это за счет того, что при десериализации при объекте сохраняется т.н. "неизвестное расширение". А при повторной сериализации это расширение используется для получения исходного двоичного образа.

---

Use case 2: Unknown Traits

Я описал этот случай вот здесь: Наследование расширением -- лучше вряд ли напишу (читать можно только до "Описание механизма subclassing_by_extension").

---

Use case 3: Protocol Versions

Так же описано: Неизвестные расширения (можно прочитать пункты Введение и Применение неизвестных расширений)

---

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

VladD2,

> ПК> Совместимость здесь вообще ни при чем. Речь шла о невозможности рефакторинга кода чужих проектов, что ты предлагал в качестве выхода в ситуации автора начального сообщения данной подветки.

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

Даже в одной конторе проблем может быть больше. Например, проекты могут находиться в разных ветках source control system. Порой библиотеки/базовые компоненты при этом интегрируют из одной ветки в другую, а вот проекты -- далеко не всегда. Далее, проектов просто может быть много, и человек, изменяющий библиотеку, далеко не всегда имеет возможность изменить все проекты, ее использующие, даже если это происходит в одной конторе.

> Что же до внешних проектов, то тут все просто. Вводятся версии и при переходе на новую версию внешние пользователи рефакторят свой код сами.

Дык, намного дешевле, если им не приходится это делать.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, eao197, Вы писали:

E>>>Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка

VD>>Извини, а сам boost::bind не является модификацией языка?

E>Языка -- нет. Стандартной библиотеки -- да.

Нет? И я могу вот так за просто получить в С++ указатель на произвольный метод?

Странно. А ведь boost::bind это море очень не быстро компилируемого кода который использует уж совсем не кчемную функциональность языка вроде указателей на методы. И все это вмесо примитивной модификации языка.

Для меня бредовость и маразматичность этой ситуации является просто приговором для этого языка. Его авторы просто костьми ложатся чтобы не признавать своих ошибок. А это гарантия ненормального развития.

Мне не хочется в очередной раз писать трактат о функциональных типах. Кажется о них было сказано уже довольно много. Ну, да если ты действительно не понимашь всю глубину маразма этой ситуации, то скажи... и я попытаюсь описать ее более детально.

VD>>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...

E>Нет. Далеко не всегда.

И когда нельзя?

E>А ты хоть прочитал, о чем там речь Если да, и нет понимания, то я готов раскрыть тему более подробно.

Раскрывай.

Здравствуйте, Павел Кузнецов

Супер! Сидел, курил, как бы от моего конкретного примера перейти на данные абстракции, а тут такое хорошее пояснение!
Паша, мой респект!

Здравствуйте, eao197, Вы писали:

E>К-хе, К-хе (смущенное покашливание), я опять согласен. Но вот наткнулся на случай, когда и функциональность нужно было чуть-чуть расширить, и интерфейс для этого заменить, и совместимость сохранить.
Как бы это было на C#. Создаем новую версию интерфейса. Старую оставляем для совместимости, но по сути вызов старых методов теперь сводится к работе через новый интерфейс. При этом старый интерфейс помечается как Obsolete. При этом если использовать старый интефейс при компиляции будут выдаваться предупреждения, а в тексте сообщения содержатся указания на то чем заменен устаревший интерфейс. Т.е. будет все примерно так:

[Obsolete("Use NewMethod instead")]
public void OldMethod(...)
{
    NewMethod(...);
}

public void NewMethod(...)
{
    // ...
}

E>Поскольку даже выпуск новой версии, с измененным интерфейсом, означал бы, что рано или поздно на него пришлось бы переходить с соответствующим рефакторингом. А так, благодоря фишкам языка, и рефакторинг не потребовался.
Программисту получают новую версию либы. Все работает как раньше, но выдаются предупреждения об использовании устаревшего интерфейса. Необходимые замены с испольщованием рефакторинга и конкретных мест, где этот устаревший интерфейс используется занимают совсем немного времени.

ЗЫ: почитал свой текст... прям сказка какая-то получается, как у маркетологов MS... и что интересно, от жизни отличается не принципиально

Здравствуйте, eao197, Вы писали:

E>Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка

Извини, а сам boost::bind не является модификацией языка?

E> -- нужен компилятор, который C++ достаточно полно поддерживает.

А может нужно немного утихомирить маразматический фанатизм? Ну, вместо 150 килобайт обмана компилятора встроить в язык примитивную конструкцию которая есть почти во всех серьезных языках?

E> Поэтому я не вижу необходимости модификации языка (чего не хочет Страус-труп) для стандартизации boost::bind (хотя boost я сейчас не использую).

И Страус-труп не видит. От того язычек и загнется. В общем, логично все хорошее загибается от крепчания маразма.

E>А что ты понимаешь под "процедурными типами", которые нужны в C++? Может ссылочку куда-нибудь дашь?

Сиии delegat & closure в какой-нить википедии.

E>Классное замечание
E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.

E>Влад, ты не понимаешь: на принимающей стороне вообще нет кода сборки с нужным классом и подгрузить его неоткуда!

Да, не понимаю. Сборка это набор байт. Всегда можно скачать...

E> Такое бывает, слово даю.

У гого?

E> Вот, например, в таких случаях: Реализация паттерна Async Completion Token

Автор: eao197
Дата: 20.05.05

.

Сто-ото не понял связи.

VladD2,

> E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

> Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.

Ты отвечаешь на другой вопрос. Речь шла об использовании твоих компонент в чужом коде.

Здравствуйте, Павел Кузнецов, Вы писали:

>> E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

>> Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.

ПК>Ты отвечаешь на другой вопрос. Речь шла об использовании твоих компонент в чужом коде.

Боюсь, что ты не понимашь меня и не потому, что я отвечаю на другой вопрос, а потому, что ты живешь в другом мире где совместимость дикая проблема.

Здравствуйте, Павел Кузнецов, Вы писали:
S>>1. Унаследовать I2 от I1 можно?
ПК>Да.
Ну, в таком случае вообше все фигня. Мы меняем сигнатуру С.f() на I2 С.f(). Все старые клиенты, содержащие код типа I1 i = c.f() продолжат прекрасно работать.

S>>2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?
ПК>Да. Но чтоб это имело смысл, придется унаследовать и все классы D, через которые клиенты получают доступ к C, а также все классы E, через которые клиенты получают доступ к D и т.п. Именно этого хочется избежать.
Ничего подобного. Классы D мы просто поменяем так, чтобы они возвращали С2, а не С1. Все клиенты, которые пользовались кодом типа

С1 с = d.getC();
I1 i = c.f();

продолжат работать. Новые клиенты смогут пользоваться вот так:

С2 с = d.getC();
I3 i = c.f();

Примечание: здесь интерфейсы I1 и I2 уже вообще не связаны между собой. Именно поэтому нам пришлось пойти на то, чтобы заменить все методы, возвращающие С1.

S>>Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?
ПК>Противоречия нет; есть масса работы, которую не хочется делать.
Я тупой. Не вижу никакой работы.
ПК>Пример:
ПК>

ПК>interface I { ... };

ПК>class C {
ПК>public:
ПК>  I1& i();
ПК>};

ПК>class D {
ПК>public:
ПК>  C& c();
ПК>};

ПК>class E {
ПК>public:
ПК>  D& d();
ПК>};
ПК>

И что? Ответный пример:

interface I { ... };
interface I2: I {...};
class C {
public:
  I2& i();
};

class D {
public:
  C& c();
};

class E {
public:
  D& d();
};

Все. Работа закончена на выделенном.

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А те, которые делают так: c.f().g(), не делая (неявного) преобразования результата c.f() к I1?
Гм. И в чем проблема? Будет ровно то же самое.

Sinclair,

> ПК>А те, которые делают так: c.f().g(), не делая (неявного) преобразования результата c.f() к I1?

> Гм. И в чем проблема? Будет ровно то же самое.

Не вполне: вызовется g() с сигнатурой из интерфейса I2, т.к. к I1 его никто не привел.

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Грабли будут, если функция по-прежнему будет назваться g(), а не advancedG().
Гм. По-моему ситуация, в которой мы наследуем новый интерфейс от существующего и нам нужна новая функция с тем же именем и сигнатурой, выглядит, мягко говоря, надуманной. Можешь привести хоть одну причину для подобного требования?

Sinclair,

> ПК>Грабли будут, если функция по-прежнему будет назваться g(), а не advancedG().

> Гм. По-моему ситуация, в которой мы наследуем новый интерфейс от существующего и нам нужна новая функция с тем же именем и сигнатурой, выглядит, мягко говоря, надуманной.

С тем же именем но новой сигнатурой. Эта новая функция скрывает старую, если старая объявлена в базовом классе.

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>С тем же именем но новой сигнатурой. Эта новая функция скрывает старую, если старая объявлена в базовом классе.
Серъезно что ли? Ты сам не пробовал?
Ок, вот тебе код:

using System;

namespace TestIntfInheritance
{
    public interface I1
    {
        int g();
    }
    public interface I2 : I1
    {
        void g(int a);
    }

    class Class1: I2
    {
        [STAThread]
        static void Main(string[] args)
        {
            Class1 self = new Class1();
            self.prop1.g();
            self.prop1.g(2);
        }
        #region I2 Members
        public void g(int a)
        {
            Console.WriteLine("I2");
        }
        #endregion

        #region I1 Members
        int TestIntfInheritance.I1.g()
        {
            Console.WriteLine("I1");
            return 0;
        }
        public I2 prop1 
        {
            get
            {
                return this;
            }
        }
        #endregion
    }
}

Как видишь, одноименные методы интерфейсов с разными сигнатурами никак друг другу не мешают. Итак, где грабли?

Sinclair,

> ПК>С тем же именем но новой сигнатурой. Эта новая функция скрывает старую, если старая объявлена в базовом классе.

> Серъезно что ли? Ты сам не пробовал? Ок, вот тебе код: <...> Как видишь, одноименные методы интерфейсов с разными сигнатурами никак друг другу не мешают. Итак, где грабли?

Это C#. Я говорил о C++. В C# было принято несколько другое решение, о том, что функции наследников скрывают не все функции базовых классов, и грабли будут в чуть более тонком случае, когда новая сигнатура окажется при разрешении перегрузки лучшим кандидатом, чем старая. Полагаю, ты подобный пример, будучи лучше знаком с C#, подберешь проще, чем я.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это C#. Я говорил о C++.

> Как бы это было на C#. Создаем новую версию интерфейса. Старую оставляем для совместимости, но по сути вызов старых методов теперь сводится к работе через новый интерфейс.

ПК>Так не выйдет. ...

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда это будет такой же стандартный механизм, как делегаты, а не заплатка.

VD>Не беспокойся — не станет. Я тут прочел твою ссылку на очередное откровение Страуструпа и понял, что основные вещи он уеж решил (ну, классы есть же?) а мелочи вроде делегатов или процедурных типов он делать не желает. Это мелкие частности. Ну, что поделать если человек настолко образован, что ему плевать на целую парадигму функционального программирования? В общем, орлам вроде Степанова и дальше прийдется извращаться, чтобы написать примитивную фичу вроде boost::bind. Причем компилироваться это будет часами. В общем, маразм крепчал...

Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка -- нужен компилятор, который C++ достаточно полно поддерживает. Поэтому я не вижу необходимости модификации языка (чего не хочет Страуструп) для стандартизации boost::bind (хотя boost я сейчас не использую).

А что ты понимаешь под "процедурными типами", которые нужны в C++? Может ссылочку куда-нибудь дашь?

E>>Ключевое слово -- "я". Если бы я мог все сам отрефакторить, я бы отрефакторил. А если я говорю своим коллегам: "Друзья мои, я сделал маленькое дополнение к библиотечке, из-за которого вы должны отрефакторить свой код", то я расчитываю услышать массу слов в свой адрес.

VD>А ты рафактри сам. Нечего сваливать на молодежь.

Классное замечание
Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

E>>Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне?

VD>Если объяснять на пальцах, то все просто... Описание классов в сборках. Если нужно его прочесть, то сборка просто динамически подгружается. Далее форматер читает информацию и можепт поднять или сериализовать любой объект. Сам объект ему по большому барабану. А технология называется рефлекшон.

Влад, ты не понимаешь: на принимающей стороне вообще нет кода сборки с нужным классом и подгрузить его неоткуда! Такое бывает, слово даю. Вот, например, в таких случаях: Реализация паттерна Async Completion Token

Автор: eao197
Дата: 20.05.05

.

Здравствуйте, eao197, Вы писали:

E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

Насколько мне известно первый версии Эклипса, до тех пор пока его архитектура окончательно не стабилизировалась, посылали такую совместимость далеко и надолго. В результате получилась нормальная система, а не набор затычек и заплаток. Так что тут надо ещё разобраться что лучше.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, eao197, Вы писали:

E>>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

IT>Насколько мне известно первый версии Эклипса, до тех пор пока его архитектура окончательно не стабилизировалась, посылали такую совместимость далеко и надолго. В результате получилась нормальная система, а не набор затычек и заплаток. Так что тут надо ещё разобраться что лучше.

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

Здравствуйте, eao197, Вы писали:

E>Про первые версии совершенно согласен. А если изменения вносятся в код, который уже несколько лет находится в stable-состоянии? Имхо, тогда совместимость становится чуть-ли не решающим фактором.

Мелкие изменения, баги, фички — для этого как правило не надо менять интерфей. Если же дархитектура меняется принципиально, то наверное лучше выпустить новый продукт, а старый только сопровождать.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, eao197, Вы писали:

E>>Про первые версии совершенно согласен. А если изменения вносятся в код, который уже несколько лет находится в stable-состоянии? Имхо, тогда совместимость становится чуть-ли не решающим фактором.

IT>Мелкие изменения, баги, фички — для этого как правило не надо менять интерфей. Если же дархитектура меняется принципиально, то наверное лучше выпустить новый продукт, а старый только сопровождать.

К-хе, К-хе (смущенное покашливание), я опять согласен. Но вот наткнулся на случай, когда и функциональность нужно было чуть-чуть расширить, и интерфейс для этого заменить, и совместимость сохранить. Поскольку даже выпуск новой версии, с измененным интерфейсом, означал бы, что рано или поздно на него пришлось бы переходить с соответствующим рефакторингом. А так, благодоря фишкам языка, и рефакторинг не потребовался.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка

VD>Извини, а сам boost::bind не является модификацией языка?

Языка -- нет. Стандартной библиотеки -- да.

E>>А что ты понимаешь под "процедурными типами", которые нужны в C++? Может ссылочку куда-нибудь дашь?

VD>Сиии delegat & closure в какой-нить википедии.

Ok, посмотрим.

E>>Влад, ты не понимаешь: на принимающей стороне вообще нет кода сборки с нужным классом и подгрузить его неоткуда!

VD>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...

Нет. Далеко не всегда.

E>> Такое бывает, слово даю.

VD>У гого?

У меня, например.

E>> Вот, например, в таких случаях: Реализация паттерна Async Completion Token

Автор: eao197
Дата: 20.05.05

.

VD>Сто-ото не понял связи.

А ты хоть прочитал, о чем там речь Если да, и нет понимания, то я готов раскрыть тему более подробно.

Здравствуйте, Павел Кузнецов, Вы писали:

согласен со всем, если речь идет о развитии библиотеки.

если же речь об неком одиночном внешнем интерфейсе, да еще который обычно используют через обертку (даже в C#), то SiAVol описал вполне приемлимый сценарий.

vdimas,

> согласен со всем, если речь идет о развитии библиотеки.
> если же речь об неком одиночном внешнем интерфейсе, да еще который обычно используют через обертку (даже в C#), то SiAVol описал вполне приемлимый сценарий.

Речь идет о случае, близком к первому варианту: http://rsdn.ru/forum/Message.aspx?mid=1195396

Автор: eao197
Дата: 30.05.05

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Так не выйдет, потому что есть некоторые промежуточные классы, возвращающие ссылки на "старые" интерфейсы, но теперь хочется, чтоб они возвращали ссылки на новые интерфейсы, т.к. эти классы используются в "новом" коде. Этих классов много. Т.е. проблема не в том, чтоб старые клиенты могли работать со старым интерфейсом, а в том, чтоб они по-старому могли работать с новым.

Посмотри списки абсолт-методов и интерфесов ко второму фрэймворку и попробуй обяснить почему это немого выйти.

ПК>Если потребовать "почкования" не только интерфейсов, но и промежуточных классов, подобных C, введя вместо них C2, то в итоге это сведется к каскадной замене I на I2 по всему коду, чего как раз и хочется избежать.

Кончай пугать людей страшилками. Погляди на реальную жизнь.

Здравствуйте, VladD2, Вы писали:

>>> E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?

>>> Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.

ПК>>Ты отвечаешь на другой вопрос. Речь шла об использовании твоих компонент в чужом коде.

VD>Боюсь, что ты не понимашь меня и не потому, что я отвечаю на другой вопрос, а потому, что ты живешь в другом мире где совместимость дикая проблема.

Совместимость здесь вообще ни при чем. Речь шла о невозможности рефакторинга кода чужих проектов, что ты предлагал в качестве выхода в ситуации автора начального сообщения данной подветки.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.
1. Унаследовать I2 от I1 можно?
2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?
Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?

Здравствуйте, eao197, Вы писали:

E>2. В качестве trx_id применяется какой-то черный ящик.

3. Guid поможет отцу маршрутизации

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, eao197, Вы писали:

E>>2. В качестве trx_id применяется какой-то черный ящик.

IT>3. Guid поможет отцу маршрутизации

Не-а, тогда все сводится к первому случаю. Маршрутизатор может передать исполнителю запрос, используя идентификатор от клиента, но когда он получает от исполнителя ответ, то как определить, какому-именно клиенту нужно ответ отдать? Либо сопрягая guid с именем клиента (тогда тот же trx_id получается), либо сохраняя guid вместе с именем клиента в БД

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.
1. Унаследовать I2 от I1 можно?
2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?
Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?

Здравствуйте, Sinclair

Коллеги, в этих абстракциях я совсем уже заблудился. Вот попробовал сделать более простое описание своей задачи: Re: А generic-и: попытка упростить описание

Автор: eao197
Дата: 25.06.05

. Может оно поможет как-то?

Sinclair,

> S>>1. Унаследовать I2 от I1 можно?

> ПК>Да.

> Ну, в таком случае вообше все фигня. Мы меняем сигнатуру С.f() на I2 С.f(). Все старые клиенты, содержащие код типа I1 i = c.f() продолжат прекрасно работать.

А те, которые делают так: c.f().g(), не делая (неявного) преобразования результата c.f() к I1?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не вполне: вызовется g() с сигнатурой из интерфейса I2, т.к. к I1 его никто не привел.
Ну и что? Где грабли-то? Вот пример:

public interface I1
{
  void g();
}

public interface I2: I1
{
  void advancedG();
}

...
c.f.g(); //старые клиенты работали и работают так.
c.f.advancedG(); // а новые могут пользоваться преимуществами.

Sinclair,

> ПК> Не вполне: вызовется g() с сигнатурой из интерфейса I2, т.к. к I1 его никто не привел.

> Ну и что? Где грабли-то?

Грабли будут, если функция по-прежнему будет назваться g(), а не advancedG().

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не вполне: вызовется g() с сигнатурой из интерфейса I2, т.к. к I1 его никто не привел.

В интерфейсе не может быть два метода содинаковыми именами и списком параметров. Новый метод будет иметь другое имя. Так что у старых клиентов все вызывется как надо, а новые просто вызовут новый метод.

Вообще-то это банальный ООП. Так мы скоро до рассуждений о структурном программировнии дойдем.

Здравствуйте, Sinclair, Вы писали:

ПК>>Грабли будут, если функция по-прежнему будет назваться g(), а не advancedG().
S>Гм. По-моему ситуация, в которой мы наследуем новый интерфейс от существующего и нам нужна новая функция с тем же именем и сигнатурой, выглядит, мягко говоря, надуманной. Можешь привести хоть одну причину для подобного требования?

Скажу больше, такой код вообще не скомплируется. Можешь попробовать компильнуть вот это:

interface I1
{
    void M1();
}

interface I2 : I1
{
    void M1();
}

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Совместимость здесь вообще ни при чем. Речь шла о невозможности рефакторинга кода чужих проектов, что ты предлагал в качестве выхода в ситуации автора начального сообщения данной подветки.

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

Что же до внешних проектов, то тут все просто. Вводятся версии и при переходе на новую версию внешние пользователи рефакторят свой код сами.

Если же есть потребность бинарной совместимости компонентов, то всегда можно решить ее средствами ООП. Одно из решений тебе тут показывал Синклер.

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