Re[15]: Версии интерфейсов
От: IT Россия linq2db.com
Дата: 24.06.05 13:46
Оценка:
Здравствуйте, eao197, Вы писали:

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


3. Guid поможет отцу маршрутизации
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Версии интерфейсов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.06.05 13:52
Оценка:
Здравствуйте, IT, Вы писали:

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


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


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Версии интерфейсов
От: IT Россия linq2db.com
Дата: 24.06.05 14:48
Оценка: +3
Здравствуйте, eao197, Вы писали:

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


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


Меня не покидает ощущение, что ты как-то всё сильно усложняешь
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.05 18:07
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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

1. Унаследовать I2 от I1 можно?
2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?
Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.05 19:28
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:
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();
};

Все. Работа закончена на выделенном.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Версии интерфейсов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.06.05 20:38
Оценка:
Здравствуйте, Sinclair

Коллеги, в этих абстракциях я совсем уже заблудился. Вот попробовал сделать более простое описание своей задачи: Re: А generic-и: попытка упростить описание
Автор: eao197
Дата: 25.06.05
. Может оно поможет как-то?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Версии интерфейсов
От: Павел Кузнецов  
Дата: 24.06.05 21:02
Оценка:
Sinclair,

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


> ПК>Да.


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


А те, которые делают так: c.f().g(), не делая (неявного) преобразования результата c.f() к I1?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[21]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.05 21:30
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А те, которые делают так: c.f().g(), не делая (неявного) преобразования результата c.f() к I1?
Гм. И в чем проблема? Будет ровно то же самое.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Версии интерфейсов
От: Павел Кузнецов  
Дата: 24.06.05 21:39
Оценка: -1
Sinclair,

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


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


Не вполне: вызовется g() с сигнатурой из интерфейса I2, т.к. к I1 его никто не привел.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[23]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.05 22:08
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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

Ну и что? Где грабли-то? Вот пример:
public interface I1
{
  void g();
}

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

...
c.f.g(); //старые клиенты работали и работают так.
c.f.advancedG(); // а новые могут пользоваться преимуществами.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Версии интерфейсов
От: Павел Кузнецов  
Дата: 24.06.05 22:46
Оценка:
Sinclair,

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


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


Грабли будут, если функция по-прежнему будет назваться g(), а не advancedG().
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[25]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.05 23:09
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Грабли будут, если функция по-прежнему будет назваться g(), а не advancedG().
Гм. По-моему ситуация, в которой мы наследуем новый интерфейс от существующего и нам нужна новая функция с тем же именем и сигнатурой, выглядит, мягко говоря, надуманной. Можешь привести хоть одну причину для подобного требования?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Версии интерфейсов
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.05 18:46
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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


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

Вообще-то это банальный ООП. Так мы скоро до рассуждений о структурном программировнии дойдем.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Версии интерфейсов
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.05 18:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

Скажу больше, такой код вообще не скомплируется. Можешь попробовать компильнуть вот это:
interface I1
{
    void M1();
}

interface I2 : I1
{
    void M1();
}
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Версии интерфейсов
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.05 18:46
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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


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

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

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

Ну, и главное. Я видил кучу проблем совместимости в С++ коде. Почему-то никакие навороты языка не спосали от них. А вот в дотнете я как бы не вижу чтобы это было проблемой. По крайней мере можно с уверенностью утверждать, что проблем в с совместимостью в дотнете как минимум не больше чем в С++.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Версии интерфейсов
От: Павел Кузнецов  
Дата: 27.06.05 16:37
Оценка: -1
Sinclair,

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


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


С тем же именем но новой сигнатурой. Эта новая функция скрывает старую, если старая объявлена в базовом классе.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[16]: Версии интерфейсов
От: Павел Кузнецов  
Дата: 27.06.05 16:42
Оценка: 1 (1) +1
VladD2,

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


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


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

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


Дык, намного дешевле, если им не приходится это делать.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[27]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.06.05 21:30
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>С тем же именем но новой сигнатурой. Эта новая функция скрывает старую, если старая объявлена в базовом классе.
Серъезно что ли? Ты сам не пробовал?
Ок, вот тебе код:
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
    }
}

Как видишь, одноименные методы интерфейсов с разными сигнатурами никак друг другу не мешают. Итак, где грабли?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Версии интерфейсов
От: Павел Кузнецов  
Дата: 27.06.05 23:58
Оценка: :)
Sinclair,

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


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


Это C#. Я говорил о C++. В C# было принято несколько другое решение, о том, что функции наследников скрывают не все функции базовых классов, и грабли будут в чуть более тонком случае, когда новая сигнатура окажется при разрешении перегрузки лучшим кандидатом, чем старая. Полагаю, ты подобный пример, будучи лучше знаком с C#, подберешь проще, чем я.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[29]: Версии интерфейсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.06.05 06:18
Оценка: 40 (1) +1 :)
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это 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. Ну так мы для того и ввели новый метод, чтобы старые клиенты более эффективно работать в случае дискретных продуктов! Если бы я этого не хотел, то я бы назвал метод по-другому.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.