Неосилятор ищет язык.

через две разные функции с разным типом параметра

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

> больше функций! вся власть функциям!

Предлагаешь ткнуть пальцем в CLOS? ;)

Не могут.

почему? если тебя смущает SomeI, то я его специально поставил заглушкой. естественный вариант для него выглядит как-то так:

struct SomeI: ISerializable, IRunnable, IFetchable {};

и далее

classA : SomeI { ... };
classB : SomeI { ... };

IInvokable же

Предлагаешь ткнуть пальцем в CLOS? ;)

утрирую. но в CLOS хорошая объектная модель, с этим я спорить не собираюсь :)

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

не паясничай, я тебе выше уже написал

IInvokable же

как ты его определишь?

как ты его определишь?

struct Invokable
{
  virtual bool invoke() = 0;
};

то есть ты предлагаешь засунуть в классы ещё по одной функции? при том, что в другом месте от них может требоваться только run(), или только serialize()?

> то есть ты предлагаешь засунуть в классы ещё по одной функции?

зачем - пишется одна реализация, от нее наследуешь класс

в другом месте от них может требоваться только run(), или только serialize()?

в другом месте они будут использоваться через другие интерфейсы - очевидно же

> если тебя смущает SomeI, то я его специально поставил заглушкой.

естественный вариант для него выглядит как-то так:

Так получается совсем другая картина. Тогда указатель на ClassC вообще нельзя передавать в invoke. С другой стороны, если смотреть только на Invoke, то совершенно не понятно зачем стока интерфейсов наплодили.

Я тут попытался подняться вверх по обсуждению, что бы понять о чём вы вообще разговор ведёте, но уловить нити рассуждений не смог.

зачем - пишется одна реализация, от нее наследуешь класс

можно код?

Я тут попытался подняться вверх по обсуждению, что бы понять о чём вы вообще разговор ведёте, но уловить нити рассуждений не смог.

о том, допустимо ли наследование интерфейсов

> допустимо ли наследование интерфейсов

Допустимо, но на практике мало полезно )

можно код?

class InvokableImp : ISerializable, IRunnable, IFetchable, IInvokable

дальше ваш код из функции

и, кстати, при таком определение исходная семантика уже нарушается: функция invoke может обладать (и вполне логично, что обладает) своим контекстом, недоступным из ClassA, ClassB и ClassC (тот же вызов History может быть не обращением к синглтону, а обращением ко внутренним данным объекта, методом которого является invoke)

дальше ваш код из функции

и по сути ты сэмулировал то самое наследование интерфейсов, только с ограничением на дальнейшее развитие архитектуры. в чём профит?

> функция invoke может обладать (и вполне логично, что обладает) своим контекстом, недоступным из ClassA, ClassB и ClassC (тот же вызов History может быть не обращением к синглтону, а обращением ко внутренним данным объекта, методом которого является invoke)

вы решаете выдуманные проблемы, точнее выдумываете их на ходу

вы решаете выдуманные проблемы, точнее выдумываете их на ходу

ну ок. пусть будут выдуманные проблемы

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

А есть на свете язык, на котором эта задача решалась бы так, чтобы тебя это решение устроило?

А есть на свете язык, на котором эта задача решалась бы так, чтобы тебя это решение устроило?

меня почти устраивают объектные модели C# (если рассматривать её с дженериками) и Go, меня вполне устраивают CLOS и классы типов Haskell

>меня почти устраивают объектные модели C# (если рассматривать её с дженериками) и Go, меня вполне устраивают CLOS и классы типов Haskell

Можешь на шарпе привести решение, которое тебя устраивает?

T someFunction<T>(T value) where T : IA, IB
{
  value.f();
  value.g();

  return value;
}

вот так, например

>вот так, например

Чем плох аналогичный код на плюсах?

Такой?

#include <boost/static_assert.hpp>
#include <boost/type_traits/is_base_of.hpp>

struct IA 
{
  virtual void f() = 0;
};

struct IB 
{
  virtual void g() = 0;
};

struct OK : IA, IB
{
  virtual void f() {}
  virtual void g() {}
};

struct FAIL
{
  void f() {}
  void g() {}
};

template <class T>
T & f(T & value)
{
  BOOST_STATIC_ASSERT((boost::is_base_of<IA, T>::value));
  BOOST_STATIC_ASSERT((boost::is_base_of<IB, T>::value));
  
  value.f();
  value.g();
  
  return value;
}

template <class T>
T & oops_f(T & value)
{
  /// Ооой. Я забыл тут constraint'ы. Но все скомпилируется (ибо template != generic)
  value.f();
  value.g();
  
  return value;
}


int main()
{
  OK ok;
  FAIL fail;
  f(ok);
//  f(fail); // <--- Тут будет ошибка компиляции. Вроде все хорошо.

  oops_f(ok);
  oops_f(fail); // Оп-па. А это скомпилируется. А С# бы не дал скомпилировать и саму функцию oops_f().

  return 0;
}

Ну и традиционное — f() и oops_f() будет компилироваться отдельно для каждого типа и если таких функций и типов будет много — бинарник ощутимо раздует. Хотя эта причина не основная, все-же накопить _столько_ инстансов без кодогенерации сложно.

>Такой?

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

бинарник ощутимо раздует

На сколько?

Хотя эта причина не основная, все-же накопить _столько_ инстансов без кодогенерации сложно.

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

>А почему в шарпе ограничения не забываются, а в плюсах забывчивость нападает?

В комментариях к коду это написано: если в C# забыть написать ограничения, то код generic'а вообще не скомпилируется: http://pastebin.com/y6W8xk2D

И это вообще реальная проблема, что найдется совершенно несвязанный класс, с тем же набором методов, с теми же сигнатурами, который возьмут и передадут и который тут совершенно не подходит?

Вполне возможно. Причем эта проблема будет трудновыловимой.

На сколько?

Прямо пропорционально количеству instance'ов N и размеру K каждого из них.

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

При чем тут рантайм и тем более эксепшены? По существу еще есть что ответить?

> Причем эта проблема будет трудновыловимой.

На плюсах ?!?

>На плюсах ?!?

да. вполне.

А можно пример кода? Только, чур, без «void *» и шаблонов.

совершенно несвязанный класс, с тем же набором методов, с теми же сигнатурами, который возьмут и передадут и который тут совершенно не подходит?

«Несвязанный» лично я понимаю, как не имеющий ни единого общего предка.

Честно говоря, не знаю. По работе приходится иметь дело с ядром 2.4, на котором Kylix идет. На 2.6 ставить не пробовал. Lazarus точно на 2.6 идет - пробовал 2 года назад, когда в институте pascal преподавали, но решил что обычный freepascal для моих лаб лучше подойдет.

>В комментариях к коду это написано: если в C# забыть написать ограничения, то код generic'а вообще не скомпилируется: http://pastebin.com/y6W8xk2D

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

Вполне возможно. Причем эта проблема будет трудновыловимой.

Да говорил бы, что это повсеместно встречается, раз уж за толстотой погнался. Даже такая надуманная проблема ограничений решается на C++ в пару строк.

Прямо пропорционально количеству instance'ов N и размеру K каждого из них.

Во-первых, это не так, во-вторых, дженерики инстанцируются точно таким же образом для каждого типа. Если тебя беспокоит лишние байты на диске, то в случае шарпа прибавь несколько сотен мегабайт исполняющей среды, без которых твоя программа не запустится, а если беспокоят байты в памяти, то в случае C++ в памяти находится только нативный код, а в случае шарпа - виртуальная машина, сборщик мусора, который заранее отъедает сколько-то для кучи, весь IL-код и нативный код, скомпиленный JIT-ом. Возможны разные варианты, но упреки в ресурсоемкости приложений от .NET - это смешно.

При чем тут рантайм и тем более эксепшены?

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

> вы решаете выдуманные проблемы

Это надо сделать девизом C++.

метко

Тсс!

> Темплейты дают гибкость утиной типизации

Ты хотел сказать «гибкость долбежки в жопу при помощи шипастой дилды»?

Delphi же. Самое то.

>Ты хотел сказать «гибкость долбежки в жопу при помощи шипастой дилды»?

Если ощущения кажутся тебе знакомыми, то спорить не буду, я в дилдах ничего не понимаю. Правда из вопроса не ясно, привлекает тебя это или отталкивает.

>А можно пример кода? Только, чур, без «void *» и шаблонов.

Какого именно кода?

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

Статическую «утку» дать не могут, согласен. Динамическая утка вполне есть — man dynamic. Впрочем и статическую утку сделать можно на уровне компилятора языка (но это будет уже не C#, конечно).

как раз из-за ограничений, поэтому многие вещи там попросту нереализуемы.

Примеры вещей?

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

Можно пример, когда (при корректно настроеном runtime) компилятор «проглотит» generic код, а JIT не осилит создать instance'ы?

Даже такая надуманная проблема ограничений решается на C++ в пару строк.

Эти строки в студию?

Во-первых, это не так, во-вторых, дженерики инстанцируются точно таким же образом для каждого типа.

И этот человек будет мне рассказывать о не знание когда и как инстанцируются дженерики. В MS CLR создается ровно 1 инстанс на все ref-type'ы (для value-types твое высказываение верно). Описаный тобой механизм используется(использовался?) в mono, но это поправимо (если еще не поправили, я давно не смотрел исходники).

сотен мегабайт исполняющей среды

Преувеличиваешь. 97 метров (mono 2.10.1). И этот размер нужен 1 раз на все программы.

Утиная типизация - это не более чем способ неконтролируемого засирания неймспейса.

> Утиная типизация - это не более чем способ неконтролируемого

засирания неймспейса.

Какой у вас опыт работы с утиной типизацией?

Достаточный чтобы понять, что утиная типизация - это не более чем способ неконтролируемого засирания неймспейса. Компиляторы пока что не научились выводить семантику метода из его реализации и контекста использования, вот в чем дело-то.

> это не более чем способ неконтролируемого засирания неймспейса

При чём тут неймспейс?

Компиляторы пока что не научились выводить семантику метода из

его реализации и контекста использования

И?

Может я конечно не умею ее готовить но утиная типизация лишь жалкое подобие интерфейсов. Вторые дают мне жесткий статический контроль типов и сигнатур когда в с первым у нас 1000 и 1 один способ выстрелить себе в ногу.

> но утиная типизация лишь жалкое подобие интерфейсов

Бог с тобой, это совершенно другой подход.

Вторые дают мне жесткий статический контроль типов

Ну вот, опять всё сводится к «статика vs динамика». Но это вопрос медицинский (к психологам), одним нравится один подход, а другим другой. Здесь нет технических аспектов, а только одни психологические.

Ну вот возьми каждую отдельную функцию и оберни в отдельный интерфейс. Положим определенной функции надо чтобы класс умел делать push и indexOf с точки утиной типизации. Это значит что класс реализует IPush и IIndexOf и функции нужны классы которые реализуют эти 2 интерфейса. Имеем строгое математическое отображение утиной типизации в интерфейсы.

> Ну вот возьми каждую отдельную функцию и оберни

в отдельный интерфейс.

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

Имеем строгое математическое отображение утиной типизации

в интерфейсы.

Хм, «стогое матемаческое» то каким боком и к чему здесь?

Я не предлагаю. Конечно логичнее группировать в цельные сущности. Это был мысленный эксперимент.

Хм, «стогое матемаческое» то каким боком и к чему здесь?

Тем что нет практической разницы между

assert(obj.push)

obj: IPush

assert(typeof(obj.push) == 'function' && obj.push.length == 1 && ... /* тут еще тонна условий чтобы как то приблизится стогой проверке компилятором */)