Re[3]: [ООП] Хочу странного
От: Кэр  
Дата: 08.03.10 11:26
Оценка: +3
Здравствуйте, 0x7be, Вы писали:

0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места? Может я что-то упускаю и идея не столь хороша, как мне кажется?


По своему последнему коду я замечаю, что у меня классы худые получаются. Дерево наследований получается очень низким и очень широким.
Т.е. даже одиночное наследование практически не используется в качестве переиспользования кода (причина — за удобство "получили поведение от родителя" приходится платить слабо контролируемым геморроем "получили поведение от родителя"). С этой точки зрения тосковать по множественному наследованию как-то не приходится.
Re: [ООП] Хочу странного
От: WolfHound  
Дата: 08.03.10 13:48
Оценка: 6 (1) +1
Здравствуйте, 0x7be, Вы писали:

0>Что если принципиально разделить эти вещи? Абстракция через обобщение в чистом виде есть во многих языка в виде интерфейсов, которые, кстати, поддерживают множественное наследование даже там, где классы поддерживают только единичное. Повторное использование кода тоже возможно другим способом — через композицию объектов.

Не тебе одному это в голову приходило.

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

Уже реалиовано: http://nemerle.org/Design_patterns
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 13:09
Оценка: 5 (2)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Extensions Methods — это синтаксический сахар, *весь* смысл которого заключается в том, что он позволяет вместо


ВВ>
ВВ>MyHelper.DoSomething(foo);
ВВ>


ВВ>писать


ВВ>
ВВ>foo.DoSomething();
ВВ>


Это не совсем так (хотя и не относится к обсуждаемой теме). Попробуй переписать следующий код без extension methods без добавления вспомогательных конструкций:

using System;
using System.Linq;

class C
{
  Func<int> f = "".Count;
}
Re[2]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.03.10 19:27
Оценка: +2
Здравствуйте, Caracrist, Вы писали:

C>По мне так недостатки отсутствия множественного наследования решены в C#

C>Extension Methods

Никакой связи между любым наследованием и extension методами нет
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[6]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 15:02
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Судя по твои словам D замечательный язык. А ты сам то его используешь?


На замечательные и красивые языки например D, Хаскель и Немерле (на этот только очень из далека) можно только любоваться.
Re[12]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 17:26
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

FR>>Мне вполне достаточно возможностей D 2.


VD>Думаю, тебе и D 1 за глаза хватило бы. Просто ты ждешь какого-то светлого будущего.


Слишком ранний старт D 2 просто убил D 1

FR>>Конечно

FR>>Ну и то что у меня нет желания осиливать Хаскель

VD>Это да. Тут тебя очень многие поймут.



Фиг с ней кривой обучения это в общем преодолимо.
Но вот то что потом надо постоянно думать это да тяжело
Re[9]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:28
Оценка: 43 (1)
Здравствуйте, samius, Вы писали:

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


N>>Нет, C# не создает неявную лямбду. Если у делегата вызвать свойство Method, то будет возвращен MethodInfo именно для extension method, а не для вспомогательного метода, сгенерированного компилятором.


S>А куда собственно девается сама строка?


Она лежит в свойстве Target у делегата.
Re[11]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:32
Оценка: 24 (1)
Здравствуйте, samius, Вы писали:

S>А можно создать такой же делегат не для екстеншн метода, а для Int32.Parse(string) например?


Да, но только через рефлекшн.
Re: [ООП] Хочу странного
От: FR  
Дата: 09.03.10 08:34
Оценка: 16 (1)
Здравствуйте, 0x7be, Вы писали:


0>Что если принципиально разделить эти вещи? Абстракция через обобщение в чистом виде есть во многих языка в виде интерфейсов, которые, кстати, поддерживают множественное наследование даже там, где классы поддерживают только единичное. Повторное использование кода тоже возможно другим способом — через композицию объектов. Единственное, чего нет — это синтаксически хорошо оформленное делегирование реализации интерфейса/части интерфейса композитам, из которых составлен класс-композиция. Но это не сложный аспект, который можно реализовать.


В D http://www.digitalmars.com/d/2.0/index.html все это уже есть, интерфейсы, множественного наследования реализации нет, но есть миксины http://www.digitalmars.com/d/2.0/mixin.html и очень мощное делегирование в виде http://www.digitalmars.com/d/2.0/class.html#AliasThis и http://www.digitalmars.com/d/2.0/operatoroverloading.html#Dispatch

В язках с утиной типизацией классов, например питон и ocaml тоже самое легко реализуется без подобных дополнительных фишек.
Re[6]: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 03:49
Оценка: 8 (1)
Здравствуйте, vdimas, Вы писали:

V>Я может чего-то не понимаю, но способ определения кода как строковой константы меня немного беспокоит. А нельзя было без взятия в двойные кавычки?


Это только один из способов и по замыслу создателей языка он предназначен только для построения EDSL.
Обычные же миксины же определятся без всяких скобок как простые шаблоны http://www.digitalmars.com/d/2.0/template-mixin.html
Re[8]: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 04:18
Оценка: 8 (1)
Здравствуйте, vdimas, Вы писали:

V>Вообще, давненько я на ВD не смотрел, в плане миксинов прикольно у них все выходит. И глобальные миксины — в этом что-то есть... как хорошее, так и не очень.

V>(Ищи потом, в какую переменную чего пишется).

Ну так все мощное опасно
Кстати контроль чтобы не писать в глобальные переменные в D сейчас легко устроить, есть чистые функции http://www.digitalmars.com/d/2.0/function.html#pure-functions и развитая ( местами даже слишком ) константность http://www.digitalmars.com/d/2.0/const3.html
Re: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 04:25
Оценка: 7 (1)
Здравствуйте, 0x7be, Вы писали:


0>Что если принципиально разделить эти вещи? Абстракция через обобщение в чистом виде есть во многих языка в виде интерфейсов, которые, кстати, поддерживают множественное наследование даже там, где классы поддерживают только единичное. Повторное использование кода тоже возможно другим способом — через композицию объектов. Единственное, чего нет — это синтаксически хорошо оформленное делегирование реализации интерфейса/части интерфейса композитам, из которых составлен класс-композиция. Но это не сложный аспект, который можно реализовать.


Почитай еще как устроенны классы в OCaml http://lj.rossia.org/community/programming/704.html в общем проблема решается за счет того что объект опознается только по сигнатуре метода (утиная типизация) а наследование чистый синтаксический сахар.
Re[3]: [ООП] Хочу странного
От: LaptevVV Россия  
Дата: 08.03.10 12:39
Оценка: 6 (1)
Здравствуйте, 0x7be, Вы писали:

LVV>>Все зависит от целей наследования и его видов.

LVV>>Вы показали только две цели наследования,
LVV>>а у Тимоти Бадда перечисляется порядка 12-14 разных целей наследования.
0>Можешь дать ссылку?
Вот в этой книжке написано
http://c2p.ru/cpp/timoti-badd-obektno-orientirovannoe-programmirovanie-v-deistvii.html
Очень книжка хорошая.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: [ООП] Хочу странного
От: fmiracle  
Дата: 09.03.10 13:02
Оценка: 4 (1)
Здравствуйте, Yuki-no Tenshi, Вы писали:

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


YNT>Можно пример( допустим, на некоем псевдокоде) работы описанного вами механизма? Или это утверждение что-то вроде "хорошо бы чтобы был мир во всем Мире"


Если я правильно понял чего хочет автор, то это действительно старая шировко известная в узких кругах вещь (потому, думаю и не пошла пока в широкие массы, что про аггрегацию и делегирование ширпотребных книг мало, а про наследование — в любом учебнике "С? за пять дней")

И выглдяит желаемое примерно так:


interface IVehile
{
   void Move();
}
interface IGun
{
   void Fire();
}

class Car : IVehile
{
  public void Move()
  {
    //some implementation
  }
  
  public void OtherMethod(){}
  public void AndOneMoreNotIntrestingMethod(){}
}

class Gun : IGun
{
  public void Fire()
  {
     //some implementation
  }
}

public class Tank: IVehile, IGun
{
   [TakeMethod( Move )]
     private Car _chassis;  //теперь у класса Tank есть собственный метод Move, взятый из класса Car. Можно вызывать tank.Move();
     
     [TakeMethod( Fire )]
     private Gun _gun;       //теперь у класса Tank есть собственный метод Fire, взятый из класса Gun. Можно вызывать tank.Fire();
     
     //но можно комбинировать и не напряму, а как в обычной агрегации
     public void LocateAndDestroy()
     {
            //IsTargetLocated & SearchTarget - реализованы тоже в этом классе каким-то там способом,
            // включая возможное собственное внутреннее состояние
            while( !IsTargetLocated )  
            {
                _chassis.Move();
                SearchTarget();
            }
            _gun.Fire();
     }
}

//никто однако не мешает сделать то же и без агрегирования любого из имеющихся объектов
public class LaserTank: IVehile, IGun
{
    [TakeMethod( Move )]
      private Car _chassis;
      
      public void Fire()
      {
         //Implement Laser Fire
      }
}

//или можно использовать метод не целиком как есть а как часть (аналог вызова base.Method):
public class RoadBuildingTank: IVehile, IGun
{
     private Car _chassis;  
     
     [TakeMethod( Fire )]
     private Gun _gun;      
     
     public void Move()
     {
        BuildRoadAtFront();
        _chassis.Move();
        DestroyRoadAtBehind();
     }
}


//одно из очевидных применений передавать объекты-агрегаты как параметры.
//В результате получим динамически создаваемые классы

class Tank : IVehile, IGun
{
   [TakeMethod( Move )]
     private ICar _chassis;  
     
     [TakeMethod( Fire )]
     private IGun _gun;
     
     public Tank( IVehile chassis, IGun gun )
     {
      _chassis = chassis;
      _gun = gun;
     }
}

//использование
var tank = new Tank( new TracksVehile(), new Gun() );
tank.Move();
tank.Fire();
var laserTank = new Tank( new TracksVehile(), new Laser() );
laserTank.Move();
laserTank.Fire();

var infantrySupport = new Tank( new Car(), new MachineGun() );



Проблема (или достоинство, это еще как посмотреть) такого подхода — отсутствие доступа к приватным членам интегрируемого класса.
Проблема — потому что уменьшаются возможности переиспользования кода
ДОстоинство — потому что уменьшается так же и связность, меньше шансов ошибиться (хотя, конечно, копи-паст тоже не путь к надежному коду )
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[6]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 10.03.10 13:40
Оценка: 4 (1)
Здравствуйте, Yuki-no Tenshi, Вы писали:

YNT>Можно пример( допустим, на некоем псевдокоде) работы описанного вами механизма? Или это утверждение что-то вроде "хорошо бы чтобы был мир во всем Мире"


Например так:
interface IInterface1
{
  void F1();
}

interface IInterface2
{
  void F2();
  void F3();
}

class A : IInterface1
{
  ...
}

class B : IInterface2
{
  ...
}

class C : IInterface1, IInterface2
{
  // Делегирование интерфейсов.
  IInterface1 = _a;
  IInterface2 = _b;

  // Явная реализация метода, перекрывает делегирование этого метода, описанное выше.
  void IInterface2.F3()
  {  
  }

  // Объявление композитов, которым будет произведено делегирование.
  private A _a = new A();
  private B _b = new B();
}
Re: [ООП] Хочу странного
От: Caracrist https://1pwd.org/
Дата: 08.03.10 13:17
Оценка: 2 (1)
Здравствуйте, 0x7be, Вы писали:


0>Данный подход не имеет тех недостатков МН, на которые упирают его противники и в то же время он обеспечивает все его возможности + кое-что сверху. Ваши мнения, коллеги?


По мне так недостатки отсутствия множественного наследования решены в C#
Extension Methods


Пишешь такие методы на интерфейсы и наследуешь сколько хочешь и по сколько хочешь раз.
~~~~~
~lol~~
~~~ Single Password Solution
Re[10]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.03.10 21:08
Оценка: 1 (1)
Здравствуйте, vdimas, Вы писали:

V>В этом-то и соль. Я из своего личного опыта высказался о том (может недоуточнил), что каждую отдельную группу стратегий удобно реализовать именно через наследование поведения.


Удобство только сомнительное. Я почему то на практике вижу от наследования реализации море проблем и практически полное отсутствие пользы. Большая часть реальных программистов применяет наследование реализации там, где оно не нжно и даже вредно. И куча дурацких книг, с дурацкими примерами из реального мира про наследование, и с полным отсутствие объяснения того простого факта, что наследование контрактов и реализаций это две большие разницы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
[ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 10:31
Оценка: +1
При спорах вида "С++ vs X", где Х — любой объектно-ориентированный ЯП, поддерживающий единичное наследование, неизбежно возникает ответвление спора на тему "множественное наследование vs. единичное наследование". Защитники МН упирают на бОльшую гибкость и возможности, которые дает МН, противники — на то, что МН усложняет реализацию языка, сам язык и что МН вообще не нужно.

Мое личное мнение состоит в том, что если рассматривать классическое ООП в стиле Smalltalk, то правы оппоненты МН. Если же рассматривать ООП и как инструмент создания архитектурного каркаса ПО, то я выступаю за МН, ибо он дает хорошие возможности по комбинации функциональности, в частности реализуя возможность mixin-style.

Теперь, собственно, к странному. А надо ли вообще в языке иметь наследование реализации в том виде, в котором это сделано в том же C++/C#/Deplhi/Java т.д.? Что в этих языках имеется в виду, когда говорится "Класс Б наследует класс А"? Имеется в виду две вещи:
1. Класс Б является подтипом А, т.е. поддерживает интерфейс класса А, и является легальным для применения везде, где можно применять А. Это Liskov substitution principle (http://en.wikipedia.org/wiki/Liskov_substitution_principle).
2. Класс Б наследует всю реализацию класса А, его поля и методы, т.е. повторно использует реализацию класса А.

Другими словами, в таком наследовании мы имеем смешение двух идей:
1. Абстракция через обобщение.
2. Повторное использование кода.

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

Данный подход не имеет тех недостатков МН, на которые упирают его противники и в то же время он обеспечивает все его возможности + кое-что сверху. Ваши мнения, коллеги?
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 11:35
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>Т.е. даже одиночное наследование практически не используется в качестве переиспользования кода (причина — за удобство "получили поведение от родителя" приходится платить слабо контролируемым геморроем "получили поведение от родителя"). С этой точки зрения тосковать по множественному наследованию как-то не приходится.

Ок, а какой способ повторного использования ты используешь и как, особенно если ты хочешь "приплести" в класс код для реализации одного из его интерфейсов? Я ратую за композицию + делегирование, но на C# делегирование выливается в ручной перевызов методов, что убивает желание этим заниматься.
Re[4]: [ООП] Хочу странного
От: servancho Россия https://dedis.ru
Дата: 08.03.10 16:37
Оценка: :)
Здравствуйте, netch80, Вы писали:

N>У множественного наследования такой проблемы нет. Да, оно может быть использовано так, что чёрт ногу сломит (в первую очередь это касается вопросов единичности или множественности включения базовых классов по разным путям иерархии; порядка инициализации подклассов...), но это IMHO не аргумент — потому что абьюзить можно абсолютно любой механизм. Но наличие МН позволяет его использовать или не использовать (например, построением прокси, включающем объекты как поля), а отсутствие заставляет применять значительно более грязные хаки. Так что я — за МН.


Вместо МН необходимо использовать агрегирование. Это позволяет получить прозрачный читаемый код. При использовании МН в реальных крупных проектах в 100% случаев это приводит к осознанию того что чего-то не предусмотрели в архитетуре и тут С++ приходит на помощь со своими костылями: приватное наследование, виртуальное наследование, mutable датамемберы, френды, безумные касты.

Не смотря на обилие пролитой в холиварах крови, пользователи как жили с глюками в продуктах так и живут.
Если руки золотые, не важно из какого места они растут.
Re[5]: [ООП] Хочу странного
От: Кэр  
Дата: 08.03.10 17:24
Оценка: +1
Здравствуйте, 0x7be, Вы писали:

0>Ок, а какой способ повторного использования ты используешь и как, особенно если ты хочешь "приплести" в класс код для реализации одного из его интерфейсов? Я ратую за композицию + делегирование, но на C# делегирование выливается в ручной перевызов методов, что убивает желание этим заниматься.


У меня просто не возникает обычно этой проблемы. Нет такого, чтобы класс являлся и тем, и вот этим, и другим, и третьим. Класс обычно наследует один интерфейс максимум. В таком виде его и тестировать и переиспользовать проще.
Re[2]: [ООП] Хочу странного
От: Воронков Василий Россия  
Дата: 09.03.10 11:00
Оценка: +1
Здравствуйте, Caracrist, Вы писали:

C>Пишешь такие методы на интерфейсы и наследуешь сколько хочешь и по сколько хочешь раз.


Extensions Methods — это синтаксический сахар, *весь* смысл которого заключается в том, что он позволяет вместо

MyHelper.DoSomething(foo);


писать

foo.DoSomething();


При этом DoSomething по-прежнему внешний статический метод, не имеющий доступа к деталям реализации Foo, а со структурами вы так еще и лишнее копирование получите.
Причем у Extensions Methods есть и немало минусов — например, очень плохо discoverability функциональности.
Re[8]: [ООП] Хочу странного
От: Воронков Василий Россия  
Дата: 09.03.10 14:07
Оценка: -1
Здравствуйте, nikov, Вы писали:

ВВ>> Какие тут дополнительные возможности дает extension method?

N>Создать делегат типа Func<int> к методу с сигнатурой int Count(IEnumerable<char>) без вспомогательных анонимных функций и явного вызова CreateDelegate.

Извини, я снова не понимаю. А что мешает-то?

public static int MyCount<TSource>(IEnumerable<TSource> source)
{
    var is2 = source as ICollection<TSource>;
    
    if (is2 != null)
        return is2.Count;
    
    var num = 0;

    foreach (var c in source)
        num++;

    return num;
}

var f = new Func<IEnumerable<Char>,Int32>(MyCount);


Выглядит это, конечно, менее красиво. Ну так сахар на то и сахар, я совершенно не против extension methods, а очень даже за.
Re[12]: [ООП] Хочу странного
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.03.10 16:35
Оценка: +1
Здравствуйте, nikov, Вы писали:

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


S>>А можно создать такой же делегат не для екстеншн метода, а для Int32.Parse(string) например?


N>Да, но только через рефлекшн.


Да, вижу. Delegate.CreateDelegate(Type, Object, MethodInfo).
Не думал просто, что MethodInfo может быть "левый" для объекта-параметра.
Re[11]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 12.03.10 00:52
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

V>>В этом-то и соль. Я из своего личного опыта высказался о том (может недоуточнил), что каждую отдельную группу стратегий удобно реализовать именно через наследование поведения.


AVK>Удобство только сомнительное. Я почему то на практике вижу от наследования реализации море проблем и практически полное отсутствие пользы. Большая часть реальных программистов применяет наследование реализации там, где оно не нжно и даже вредно. И куча дурацких книг, с дурацкими примерами из реального мира про наследование, и с полным отсутствие объяснения того простого факта, что наследование контрактов и реализаций это две большие разницы.


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

Самые основные плюсы каждой технологии:

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

2. Компонентное программирование — создает предпосылки для безопасного проектирования в рамках структурных паттернов, не боясь, что неверная реализация что-то испортит в дизайне, тем более, что реализацию каждого отдельного "кирпича" можно заменить без серьезных последствий. Цель компонентного программирования — обеспечение устойчивости дизайна, и создание безопасных зон для п.1.

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

Опять много наспамил, сорри, но не могу не добавить. Когда техника ООП развивалась, и нарабатывались ее практики, то размер ТЕХ задач был сопоставим с современными локальными задачами. Вот и ответ на все вопросы бытия, вот и граница применимости ООП технологии — небольшие изолированные иерархии.
Re[16]: [ООП] Хочу странного
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.10 19:24
Оценка: :)
Здравствуйте, vdimas, Вы писали:

AVK>>Путанницу создаешь ты, когда приплетаешь вещи, к разговору вообще не имеющие никакого отношения. И когда сильно загаживаешь свои сообщения абсолютно левыми философствованиями. Тебя читать невозможно.


V>Ну накопилось... Ты все время повторяешь "контракты, контракты", хотелось ясности.


Он в широком смысле использует, а не в узком, что в контрактном-программировании.
Re[18]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.03.10 16:30
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

AVK>>Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?


LP>Эти — не нужно.


С ЯП очень похожая ситуация. По тем же самым причинам.

LP>Формализация знаний должна производиться экспертами. См. экспертные системы.


Эксперты существуют для того, чтобы получать оценку там, где формализацию обеспечить не выходит. Погляди на мои примеры — там как раз никакой формализации не получается, поэтому в этих областях используют экспертную оценку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
AVK Blog
Re[19]: [ООП] Хочу странного
От: LaPerouse  
Дата: 15.03.10 17:58
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?

LP>>Эти — не нужно.
AVK>С ЯП очень похожая ситуация. По тем же самым причинам.

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

LP>>Формализация знаний должна производиться экспертами. См. экспертные системы.


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


Экспертная оценка и в самом деле не имеет никакого отношения к тому, о чем я говорю.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.03.10 10:46
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Теперь, собственно, к странному. А надо ли вообще в языке иметь наследование реализации в том виде, в котором это сделано в том же C++/C#/Deplhi/Java т.д.?


Что в ней странного? Довольно старая и очевидная идея. Из последнего, ЕМНИП, гуглевый Go такой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[2]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 11:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

0>>Теперь, собственно, к странному. А надо ли вообще в языке иметь наследование реализации в том виде, в котором это сделано в том же C++/C#/Deplhi/Java т.д.?

AVK>Что в ней странного? Довольно старая и очевидная идея. Из последнего, ЕМНИП, гуглевый Go такой.
Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места? Может я что-то упускаю и идея не столь хороша, как мне кажется?
Re: [ООП] Хочу странного
От: dotneter  
Дата: 08.03.10 11:01
Оценка:
Здравствуйте, 0x7be, Вы писали:

Нужны интерфейсы и множественная диспетчеризация, все остальное от лукавого.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[2]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 11:13
Оценка:
Здравствуйте, dotneter, Вы писали:

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

Ну, множественная multiple dispatch — это штука хорошая, только она лежит в стороне от обсуждаемой темы.
Re[3]: [ООП] Хочу странного
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 08.03.10 11:26
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


0>>>Теперь, собственно, к странному. А надо ли вообще в языке иметь наследование реализации в том виде, в котором это сделано в том же C++/C#/Deplhi/Java т.д.?

AVK>>Что в ней странного? Довольно старая и очевидная идея. Из последнего, ЕМНИП, гуглевый Go такой.
0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места? Может я что-то упускаю и идея не столь хороша, как мне кажется?

Например, потому, что сходство поведения влечёт за собой в большинстве случаев идентичные реализации методов. И если в C++ достаточно сделать базовый класс реализации, то в Go придётся или повторять код, или хотя бы повторять вызовы функций вне этих классов. А всякое подобное дублирование — источник засорения мозгов, китайского copy&paste и пложения трудноуловимых ошибок.

У множественного наследования такой проблемы нет. Да, оно может быть использовано так, что чёрт ногу сломит (в первую очередь это касается вопросов единичности или множественности включения базовых классов по разным путям иерархии; порядка инициализации подклассов...), но это IMHO не аргумент — потому что абьюзить можно абсолютно любой механизм. Но наличие МН позволяет его использовать или не использовать (например, построением прокси, включающем объекты как поля), а отсутствие заставляет применять значительно более грязные хаки. Так что я — за МН.
The God is real, unless declared integer.
Re: [ООП] Хочу странного
От: LaptevVV Россия  
Дата: 08.03.10 11:44
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Другими словами, в таком наследовании мы имеем смешение двух идей:

0>1. Абстракция через обобщение.
0>2. Повторное использование кода.
Все зависит от целей наследования и его видов.
Вы показали только две цели наследования,
а у Тимоти Бадда перечисляется порядка 12-14 разных целей наследования.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: [ООП] Хочу странного
От: dotneter  
Дата: 08.03.10 11:56
Оценка:
Здравствуйте, 0x7be, Вы писали:

Как у вас выглядит реализация
class A { virtual void DoSomething(){}}

class B:A { 
    override void DoSomething(){ 
        DoAdditionalStuff();
        base.DoSomething();
    }
}

?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 12:04
Оценка:
Здравствуйте, netch80, Вы писали:

N>Например, потому, что сходство поведения влечёт за собой в большинстве случаев идентичные реализации методов. И если в C++ достаточно сделать базовый класс реализации, то в Go придётся или повторять код, или хотя бы повторять вызовы функций вне этих классов. А всякое подобное дублирование — источник засорения мозгов, китайского copy&paste и пложения трудноуловимых ошибок.

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

N>Но наличие МН позволяет его использовать или не использовать (например, построением прокси, включающем объекты как поля), а отсутствие заставляет применять значительно более грязные хаки. Так что я — за МН.

ИМХО, делегирование более гибкий механизм. Кстати, что за грязные хаки ты имеешь в виду?
Re[2]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 12:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, 0x7be, Вы писали:


LVV>Все зависит от целей наследования и его видов.

LVV>Вы показали только две цели наследования,
LVV>а у Тимоти Бадда перечисляется порядка 12-14 разных целей наследования.
Можешь дать ссылку?
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 12:19
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, 0x7be, Вы писали:


D>Как у вас выглядит реализация

D>...?
Как частный случай вполне может быть.
А что?
Re[5]: [ООП] Хочу странного
От: dotneter  
Дата: 08.03.10 12:31
Оценка:
Здравствуйте, 0x7be, Вы писали:

Как я понимаю, вы предлагаете отказатся от наследования, соответственно мне бы хотелось увидить как бы выгдятел этот код в вашем случае.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[6]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 12:34
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Как я понимаю, вы предлагаете отказатся от наследования, соответственно мне бы хотелось увидить как бы выгдятел этот код в вашем случае.

Понятно. Выглядел бы он следующим образом:
interface IA
{
    void DoSomething();
}

class A : IA
{ 
    void DoSomething(){}
}

class B : IA
{ 
    override void DoSomething()
    { 
        DoAdditionalStuff();
        _a.DoSomething();
    }
    private A _a = new A();
}
Re[7]: [ООП] Хочу странного
От: dotneter  
Дата: 08.03.10 12:47
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


D>>Как я понимаю, вы предлагаете отказатся от наследования, соответственно мне бы хотелось увидить как бы выгдятел этот код в вашем случае.

0>Понятно. Выглядел бы он следующим образом:
0>
0>interface IA
0>{
0>    void DoSomething();
0>}

0>class A : IA
0>{ 
0>    void DoSomething(){}
0>}

0>class B : IA
0>{ 
0>    override void DoSomething()
0>    { 
0>        DoAdditionalStuff();
0>        _a.DoSomething();
0>    }
0>    private A _a = new A();
0>}
0>

Тоесть, если у нас
interface IA {int X {get;set;}}
и
DoAdditionalStuff() { X = 0;}

Придется делегировать X из А, а если полей с десяток?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[8]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 14:40
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Тоесть, если у нас

D>interface IA {int X {get;set;}}
D>и
D>DoAdditionalStuff() { X = 0;}
D>Придется делегировать X из А, а если полей с десяток?
Естественно, придется делегировать. Я в изначальном посте указал, что для того, о чем я говорю, требуется определенная поддержка со стороны ЯП, иначе придется прописывать все делегации руками. Я не предлагаю свою идею, как стиль программирования на C#
Re[2]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 14:43
Оценка:
Здравствуйте, Caracrist, Вы писали:

C>По мне так недостатки отсутствия множественного наследования решены в C#

C>Extension Methods
C>
C>Пишешь такие методы на интерфейсы и наследуешь сколько хочешь и по сколько хочешь раз.
Гм... чот не въехал, как с их помощью реализовать mixins. Можешь привести пример?
Re[3]: [ООП] Хочу странного
От: Caracrist https://1pwd.org/
Дата: 08.03.10 14:53
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


C>>По мне так недостатки отсутствия множественного наследования решены в C#

C>>Extension Methods
C>>
C>>Пишешь такие методы на интерфейсы и наследуешь сколько хочешь и по сколько хочешь раз.
0>Гм... чот не въехал, как с их помощью реализовать mixins. Можешь привести пример?
Помоги, приведи конкретную задачу.
~~~~~
~lol~~
~~~ Single Password Solution
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 15:03
Оценка:
Здравствуйте, Caracrist, Вы писали:

0>>Гм... чот не въехал, как с их помощью реализовать mixins. Можешь привести пример?

C>Помоги, приведи конкретную задачу.
Есть стандартный интерфейс INotifyPropertyChanged (System.ComponentModel). Есть некая его библиотечная реализация, целиком ортогональная иерархии предметных классов. Назовем её MyNotifyPropertyChanged.
Есть класс:
public class MyBusinessClass : MyBusinessClassBase, INotifyPropertyChanged 
{
  ...
}

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

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

Код класс MyNotifyPropertyChanged выглядит примерно так:
public class MyNotifyPropertyChanged : INotifyPropertyChanged
{
  public event PropertyChangedEventHandler PropertyChanged = () => { };
  
  public void SendPropertyChanged(...)
  {
    ...
  }
}
Re[9]: [ООП] Хочу странного
От: dotneter  
Дата: 08.03.10 15:20
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Естественно, придется делегировать. Я в изначальном посте указал, что для того, о чем я говорю, требуется определенная поддержка со стороны ЯП, иначе придется прописывать все делегации руками. Я не предлагаю свою идею, как стиль программирования на C#


И чем это лучше наследования?
Можно договорится использовать везде интерфейсы а запись вида class B: A считать делегированием.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[5]: [ООП] Хочу странного
От: Caracrist https://1pwd.org/
Дата: 08.03.10 15:22
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Есть стандартный интерфейс

Да, тут проблема, интерфейс нужно имплементить уже в классе...
Вот если свой писать. Хотя тогда появляются проблемы с оверлоадом.

В общем ты прав, полностью это проблему не решает, но позволяет задизайнить с нуля интерфейсы так чтобы их можно было частично реализовывать... А вот со стандартными уже никуда не денешся.
~~~~~
~lol~~
~~~ Single Password Solution
Re[2]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.03.10 15:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Что в ней странного? Довольно старая и очевидная идея. Из последнего, ЕМНИП, гуглевый Go такой.


А какие в нем средства повторного использования реализаций?
Или за одные канает утиная типизация для интерфейсов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.03.10 15:30
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места? Может я что-то упускаю и идея не столь хороша, как мне кажется?


А в нем много чего не нашло места исключительно по дури. Рука рынка. Она сама все настраивает. Вот только не так как хочется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [ООП] Хочу странного
От: anton_t Россия  
Дата: 08.03.10 15:43
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, 0x7be, Вы писали:


0>>Естественно, придется делегировать. Я в изначальном посте указал, что для того, о чем я говорю, требуется определенная поддержка со стороны ЯП, иначе придется прописывать все делегации руками. Я не предлагаю свою идею, как стиль программирования на C#


D>И чем это лучше наследования?

D>Можно договорится использовать везде интерфейсы а запись вида class B: A считать делегированием.

В случае наследования связность между A и B гораздо больше. А в случае с композицией эту связь можно вообще убрать:

interface IA
{
    void DoSomething();
}

class A : IA
{ 
    void DoSomething(){}
}

class B : IA
{ 
    public B (IA a)
    {
        _a = a;
    }

    override void DoSomething()
    { 
        DoAdditionalStuff();
        _a.DoSomething();
    }

    private IA _a;
}
Re[6]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 16:04
Оценка:
Здравствуйте, Caracrist, Вы писали:

C>Да, тут проблема, интерфейс нужно имплементить уже в классе...

C>Вот если свой писать. Хотя тогда появляются проблемы с оверлоадом.
C>В общем ты прав, полностью это проблему не решает, но позволяет задизайнить с нуля интерфейсы так чтобы их можно было частично реализовывать... А вот со стандартными уже никуда не денешся.
Ладно, давай представим, это не стандартный интерфейс. Как бы ты тогда выкрутился с extension-методами?
Re[10]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 16:07
Оценка:
Здравствуйте, dotneter, Вы писали:

D>И чем это лучше наследования?

1. Можно делегировать нескольким объектам. В принципе, получается почти тоже самое, что и множественное наследование, но без его трудностей.
2. Можно подменять делегат на ходу.
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 16:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А в нем много чего не нашло места исключительно по дури. Рука рынка. Она сама все настраивает. Вот только не так как хочется.

Мне тут люди возражают, так что не все дело в рынке Просто это традиция такая, если ООП — значит три кита и все такое. Как и любая другая традиция, эта закрепилась просто в силу человеческой природы
Re[11]: [ООП] Хочу странного
От: dotneter  
Дата: 08.03.10 16:15
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


D>>И чем это лучше наследования?

0>1. Можно делегировать нескольким объектам. В принципе, получается почти тоже самое, что и множественное наследование, но без его трудностей.
Насколько я помню единственная проблема там это ромбы, вроде и здесь их можно построить.
0>2. Можно подменять делегат на ходу.
Вам известен язык в котором это реализовано?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[12]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 08.03.10 16:17
Оценка:
Здравствуйте, dotneter, Вы писали:

D>>>И чем это лучше наследования?

0>>1. Можно делегировать нескольким объектам. В принципе, получается почти тоже самое, что и множественное наследование, но без его трудностей.
D>Насколько я помню единственная проблема там это ромбы, вроде и здесь их можно построить.
Это концептуальная проблема. Но есть и проблемы реализации множественного наследования, из-за которых от него в некоторых языка отказываются.

0>>2. Можно подменять делегат на ходу.

D>Вам известен язык в котором это реализовано?
Если не ошибаюсь, в CLOS можно такие вещи реализовать. Ну и в любом другом ОО-языке, если заморачиваться ручным делегированием интерфейса
Re[5]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.03.10 16:22
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Мне тут люди возражают, так что не все дело в рынке Просто это традиция такая, если ООП — значит три кита и все такое. Как и любая другая традиция, эта закрепилась просто в силу человеческой природы


Ты плохо знаешь человеческую природу. Человеческое мнение это в 99% случаев то, что ему вдували. Чем дольше вдували, тем крепче мнение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [ООП] Хочу странного
От: Yuki-no Tenshi Украина  
Дата: 08.03.10 16:56
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


Можно пример( допустим, на некоем псевдокоде) работы описанного вами механизма? Или это утверждение что-то вроде "хорошо бы чтобы был мир во всем Мире"
雪の天使
Re[3]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.03.10 19:27
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места?


Слишком радикально для мейнстрима?

0> Может я что-то упускаю и идея не столь хороша, как мне кажется?


Много хороший идей в мейнстриме отсутствует, тут уж ничего не попишешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[3]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.03.10 19:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А какие в нем средства повторного использования реализаций?

VD>Или за одные канает утиная типизация для интерфейсов?

Я, честно говоря, мог попутать Go с чем то еще на гугле. В том языке, про который речь, вроде бы были встроенные в него миксины.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[4]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.03.10 21:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Я, честно говоря, мог попутать Go с чем то еще на гугле. В том языке, про который речь, вроде бы были встроенные в него миксины.


Интересно с чем? В Гоу вроде бы их не было. Хотя может это я ошибаюсь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: [ООП] Хочу странного
От: LordMAD Россия  
Дата: 09.03.10 07:52
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Что если принципиально разделить эти вещи? Абстракция через обобщение в чистом виде есть во многих языка в виде интерфейсов, которые, кстати, поддерживают множественное наследование даже там, где классы поддерживают только единичное. Повторное использование кода тоже возможно другим способом — через композицию объектов. Единственное, чего нет — это синтаксически хорошо оформленное делегирование реализации интерфейса/части интерфейса композитам, из которых составлен класс-композиция. Но это не сложный аспект, который можно реализовать.


Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0). Аналогичную возможность обещали в c# 4.0
Re[2]: [ООП] Хочу странного
От: FR  
Дата: 09.03.10 08:38
Оценка:
С миксинами чуть промахнулся http://www.digitalmars.com/d/2.0/template-mixin.html
Re[4]: [ООП] Хочу странного
От: FR  
Дата: 09.03.10 08:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Я, честно говоря, мог попутать Go с чем то еще на гугле. В том языке, про который речь, вроде бы были встроенные в него миксины.


Скорее всего с D попутал.
Re[5]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.03.10 10:37
Оценка:
Здравствуйте, FR, Вы писали:

FR>Скорее всего с D попутал.


В D нет наследования реализации?
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[2]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.03.10 10:37
Оценка:
Здравствуйте, LordMAD, Вы писали:

LMA>Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0).


Только для СОМ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[6]: [ООП] Хочу странного
От: FR  
Дата: 09.03.10 10:43
Оценка:
Здравствуйте, AndrewVK, Вы писали:

FR>>Скорее всего с D попутал.


AVK>В D нет наследования реализации?


Одиночное есть, множественного нет, для интерфейсов множественное есть.
Но при тех средствах что в нем доступны миксины, алиасы this и диспетчеризации вызовов, можно при желании легко обойтись без наследования вообще
Re[7]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.03.10 10:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Одиночное есть, множественного нет, для интерфейсов множественное есть.


Речь про то, чтобы наследование реализации совсем убрать. Любое.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[8]: [ООП] Хочу странного
От: FR  
Дата: 09.03.10 11:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Речь про то, чтобы наследование реализации совсем убрать. Любое.


В том D который есть сейчас это вполне реально, во всяком случае писание в таком стиле
никаких неудобств не вызовет.
Re[6]: [ООП] Хочу странного
От: fmiracle  
Дата: 09.03.10 13:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


0>>Мне тут люди возражают, так что не все дело в рынке Просто это традиция такая, если ООП — значит три кита и все такое. Как и любая другая традиция, эта закрепилась просто в силу человеческой природы


VD>Ты плохо знаешь человеческую природу. Человеческое мнение это в 99% случаев то, что ему вдували. Чем дольше вдували, тем крепче мнение.


Так он вобщем-то про то и говорит. Много вдули — закрепилась традиция. И теперь новый ООП-язык без наследования поведения широкая аудитория воспримет как минимум странно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[4]: [ООП] Хочу странного
От: Воронков Василий Россия  
Дата: 09.03.10 13:30
Оценка:
Здравствуйте, nikov, Вы писали:

Честно, не вижу подвоха, а чем проблема? Собственно, берем реализацию, которую показывает рефлектор:

public static int Count<TSource>(this IEnumerable<TSource> source)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    ICollection<TSource> is2 = source as ICollection<TSource>;
    if (is2 != null)
    {
        return is2.Count;
    }
    int num = 0;
    using (IEnumerator<TSource> enumerator = source.GetEnumerator())
    {
        while (enumerator.MoveNext())
        {
            num++;
        }
    }
    return num;
}


Где здесь магия? Все то же самое можно представить в виде обычного метода.
Re[5]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 13:31
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Где здесь магия? Все то же самое можно представить в виде обычного метода.


Но нельзя создать делегат.
Re[6]: [ООП] Хочу странного
От: Воронков Василий Россия  
Дата: 09.03.10 13:37
Оценка:
Здравствуйте, nikov, Вы писали:

ВВ>>Где здесь магия? Все то же самое можно представить в виде обычного метода.

N>Но нельзя создать делегат.

Почему нельзя?


public static Func<Int32> Count<TSource>(this IEnumerable<TSource> source)
        {
            Func<Int32> f = () => {
                    if (source == null)
                    {
                        //throw Error.ArgumentNull("source");
                    }
                    ICollection<TSource> is2 = source as ICollection<TSource>;
                    if (is2 != null)
                    {
                        return is2.Count;
                    }
                    int num = 0;
                    using (IEnumerator<TSource> enumerator = source.GetEnumerator())
                    {
                        while (enumerator.MoveNext())
                        {
                            num++;
                        }
                    }
                    return num;
                };
            return f;
        }


Строка имеет интерфейс IEnumerable<Char>. Через этот интерфейс мы можем делать все что нам хочется — в т.ч. и считать кол-во чаров по условию, например. Какие тут дополнительные возможности дает extension method?
Re[7]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 13:40
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ> Какие тут дополнительные возможности дает extension method?


Создать делегат типа Func<int> к методу с сигнатурой int Count(IEnumerable<char>) без вспомогательных анонимных функций и явного вызова CreateDelegate.
Re[9]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 14:12
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>>> Какие тут дополнительные возможности дает extension method?

N>>Создать делегат типа Func<int> к методу с сигнатурой int Count(IEnumerable<char>) без вспомогательных анонимных функций и явного вызова CreateDelegate.

ВВ>Извини, я снова не понимаю. А что мешает-то?


ВВ>
ВВ>var f = new Func<IEnumerable<Char>,Int32>(MyCount);
ВВ>


Ну посмотри внимательно: у тебя делегат типа Func<IEnumerable<Char>,Int32>, то есть он принимает параметр IEnumerable<Char>. А надо создать делегат Func<int> (не принимающий параметров) к тому же методу, передав аргумент при создании делегата.
Re[6]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.03.10 15:51
Оценка:
Здравствуйте, nikov, Вы писали:

ВВ>>Где здесь магия? Все то же самое можно представить в виде обычного метода.


N>Но нельзя создать делегат.


Чё правда что ли?

Блин, а зачем ты тогда меня для Немерла это заставил сделать? Я то думал, так в шарпе можно. Часа 3 убил на реализацию .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 15:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ВВ>>>Где здесь магия? Все то же самое можно представить в виде обычного метода.


N>>Но нельзя создать делегат.


VD>Чё правда что ли?


VD>Блин, а зачем ты тогда меня для Немерла это заставил сделать? Я то думал, так в шарпе можно. Часа 3 убил на реализацию .


Нельзя с обычным static методом, но можно с extension методом. Ведь в Nemerle так же?
Re[4]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.03.10 15:58
Оценка:
Здравствуйте, nikov, Вы писали:

N>Это не совсем так (хотя и не относится к обсуждаемой теме). Попробуй переписать следующий код без extension methods без добавления вспомогательных конструкций:


N>
N>using System;
N>using System.Linq;

N>class C
N>{
N>  Func<int> f = "".Count;
N>}
N>


Гы. Легко! Только нужно выбрать правильный язык (Nemerle)!
def f : Func[int] = "a".Count;
WriteLine(f());
_ = ReadLine();

или даже так (без делегата):
def f = "a".Count;
WriteLine(f());
_ = ReadLine();


Интересно, а у F# как с этим примером? Особенно интересен первый варинат. Второй он ведь явно должен поддерживать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


N>>Это не совсем так (хотя и не относится к обсуждаемой теме). Попробуй переписать следующий код без extension methods без добавления вспомогательных конструкций:


N>>
N>>using System;
N>>using System.Linq;

N>>class C
N>>{
N>>  Func<int> f = "".Count;
N>>}
N>>


VD>Гы. Легко! Только нужно выбрать правильный язык (Nemerle)!

VD>
VD>def f : Func[int] = "a".Count;
VD>WriteLine(f());
VD>_ = ReadLine();
VD>


И где же здесь "без extension methods"?
Re[8]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.03.10 16:11
Оценка:
Здравствуйте, nikov, Вы писали:

VD>>Блин, а зачем ты тогда меня для Немерла это заставил сделать? Я то думал, так в шарпе можно. Часа 3 убил на реализацию .


N>Нельзя с обычным static методом, но можно с extension методом. Ведь в Nemerle так же?


Ну, если у static-метода только один параметр, то конечно нельзя, так как синтаксис частичного применения пересечется с синтаксисом вызова. В таких случаях прийдется явно лямбду указать:
def f = () => MyCount("");

Если параметров больше, то можно частичное применение использовать.

Но в твоем примере ведь явно метод-ресширение используется. Причем тут "обычный static метод"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Но в твоем примере ведь явно метод-ресширение используется.

Да.

VD>Причем тут "обычный static метод"?

Я утверждал, что мой пример нельзя переписать на C# без использования extension методов, то есть пользуясь лишь обычными static методами.
Re[6]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.03.10 16:14
Оценка:
Здравствуйте, nikov, Вы писали:

N>И где же здесь "без extension methods"?


А, понял... "без" я проглядел.
Ну, знаешь, в таких случаях не грех и "вспомогательную конструкцию" в виде "() =>" добавить. Один фиг любые средсва здесь будут создавать неявню лямбду.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.03.10 16:15
Оценка:
Здравствуйте, nikov, Вы писали:

N>Я утверждал, что мой пример нельзя переписать на C# без использования extension методов, то есть пользуясь лишь обычными static методами.


Понял. А что где-то можно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А, понял... "без" я проглядел.

VD>Ну, знаешь, в таких случаях не грех и "вспомогательную конструкцию" в виде "() =>" добавить. Один фиг любые средсва здесь будут создавать неявню лямбду.

Нет, C# не создает неявную лямбду. Если у делегата вызвать свойство Method, то будет возвращен MethodInfo именно для extension method, а не для вспомогательного метода, сгенерированного компилятором.
Re[11]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:20
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Я утверждал, что мой пример нельзя переписать на C# без использования extension методов, то есть пользуясь лишь обычными static методами.


VD>Понял. А что где-то можно?


Вроде бы нигде. Я только хотел показать, что extension methods — это не всегда просто синтаксический сахар, который можно переписать через обычные статики.
Re[8]: [ООП] Хочу странного
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.03.10 16:27
Оценка:
Здравствуйте, nikov, Вы писали:

N>Нет, C# не создает неявную лямбду. Если у делегата вызвать свойство Method, то будет возвращен MethodInfo именно для extension method, а не для вспомогательного метода, сгенерированного компилятором.


А куда собственно девается сама строка?
Re[10]: [ООП] Хочу странного
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.03.10 16:30
Оценка:
Здравствуйте, nikov, Вы писали:

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


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


N>>>Нет, C# не создает неявную лямбду. Если у делегата вызвать свойство Method, то будет возвращен MethodInfo именно для extension method, а не для вспомогательного метода, сгенерированного компилятором.


S>>А куда собственно девается сама строка?


N>Она лежит в свойстве Target у делегата.


А можно создать такой же делегат не для екстеншн метода, а для Int32.Parse(string) например?
Re[12]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:33
Оценка:
Здравствуйте, nikov, Вы писали:

S>>А можно создать такой же делегат не для екстеншн метода, а для Int32.Parse(string) например?


N>Да, но только через рефлекшн.


Ну или с помощью IL.
Re[8]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.03.10 16:34
Оценка:
Здравствуйте, nikov, Вы писали:


VD>>Ну, знаешь, в таких случаях не грех и "вспомогательную конструкцию" в виде "() =>" добавить. Один фиг любые средсва здесь будут создавать неявню лямбду.


N>Нет, C# не создает неявную лямбду. Если у делегата вызвать свойство Method, то будет возвращен MethodInfo именно для extension method, а не для вспомогательного метода, сгенерированного компилятором.


Это как это? У тебя сигнатуры не совпадают. Как мам можно без промежуточной функции обойтись?
Требуемый тип функции void -> int, у метода расширения или статического метода тип IEnumerable[char] -> int. Как не крути, а надо создавать функцию-переходник.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 09.03.10 16:52
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Нет, C# не создает неявную лямбду. Если у делегата вызвать свойство Method, то будет возвращен MethodInfo именно для extension method, а не для вспомогательного метода, сгенерированного компилятором.


VD>Это как это? У тебя сигнатуры не совпадают. Как мам можно без промежуточной функции обойтись?

VD>Требуемый тип функции void -> int, у метода расширения или статического метода тип IEnumerable[char] -> int. Как не крути, а надо создавать функцию-переходник.

Нет, делегаты начиная с .NET 2.0 достаточно гибкие для этого. Об этом написано в документации для метода CreateDelegate, но то же самое справедливо и для вызова конструктора делегата, который создает компилятор C#.

The delegate type and the method must have compatible return types. That is, the return type of method must be assignable to the return type of type.

If firstArgument is supplied, it is passed to method every time the delegate is invoked; firstArgument is said to be bound to the delegate, and the delegate is said to be closed over its first argument. If method is static (Shared in Visual Basic), the argument list supplied when invoking the delegate includes all parameters except the first; if method is an instance method, then firstArgument is passed to the hidden instance parameter (represented by this in C#, or by Me in Visual Basic).

If firstArgument is supplied, the first parameter of method must be a reference type, and firstArgument must be compatible with that type.

Re[3]: [ООП] Хочу странного
От: LordMAD Россия  
Дата: 10.03.10 05:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

LMA>>Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0).


AVK>Только для СОМ.


Совсем нет.

type
  IMyInterface = interface
    procedure Method1;
  end;

  TMyImpl = class (TInterfacedObject, IMyInterface)
    procedure Method1;
  end;

  TMyClass = class(TObject, IMyInterface)
    FMyInterface: IMyInterface;
    property MyInterface: IMyInterface read FMyInterface
      implements IMyInterface;
  end;

procedure TMyImpl.Method1;
begin
  ShowMessage('TMyImpl.Method1');
end;

procedure foo;
var
  MyClass: TMyClass;
  MyInterface: IMyInterface;
begin
  MyClass := TMyClass.Create;
  MyClass.FMyInterface := TMyImpl.Create;
  MyInterface := MyClass;
  MyInterface.Method1;
end;
Re[3]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 10.03.10 10:59
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места? Может я что-то упускаю и идея не столь хороша, как мне кажется?


Механизм реализации полиморфизма через плоскую таблицу виртуальных ф-ий делает такую реализацию затруднительной. Тут надо извращаться, для интерфейсов — своя таблица, для обычного наследования — своя. И если в дотнете, например, рантайм упорядочивает таблицу интерфейсов, то кто будет ее упорядочивать в нативных языках м/у независимыми модулями-dll?

Подобную технику, кстати, запросто можно сделать на платформе .Net, но нужен соотв. язык, который будет компилировать миксины например как value-type, для того, чтобы размещать их "в теле" класов, и нужна некая конструкция, которая будет указывать, какой интерфейс каким миксином обрабатывается (или даже с точностью до отдельных методов).

Кстати, у тебя есть идея, как бы это могло синтаксически выглядеть в синтаксисе С++подобных языков? (типа Java/C#)
Re[7]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 10.03.10 11:07
Оценка:
Здравствуйте, fmiracle, Вы писали:



F>//одно из очевидных применений передавать объекты-агрегаты как параметры.

F>//В результате получим динамически создаваемые классы

Угу, только хотел сказать, что в результате все дружно начнут раскладывать функциональность классов на бихейворы, стратегии и прочие поведенческие паттерны. Фишка в том, что если стратегий много и они сложны, то удобнее всего их реализовывать с применением обычного ООП полиморфизма, с наследованием кода. А иначе все дойдет до маразма, т.е. потребует рекурсивно все раскладывать на простейшие "ячейки" функциональности, умножая многократно кол-во сущностей, которыми придется оперировать.
Re[12]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 10.03.10 12:38
Оценка:
Здравствуйте, nikov, Вы писали:

S>>А можно создать такой же делегат не для екстеншн метода, а для Int32.Parse(string) например?


N>Да, но только через рефлекшн.


Офигеть, замыкание по одной переменной без доп. степени косвенности.
Ну-ка карринг:

using System;

namespace ConsoleApplication3
{

    class StaticFunctions
    {
        private static readonly char[] s_defSplits = { ' ', '\t', '\n' };

        public static string[] Split(string str)
        {
            return str.Split(s_defSplits, StringSplitOptions.RemoveEmptyEntries);
        }

        public static string[] SplitCustom(char[] split, string str)
        {
            return str.Split(split, StringSplitOptions.RemoveEmptyEntries);
        }
    }



    class Program
    {

        public static Func<T2, TResult> Bind1st<T1, T2, TResult>(Func<T1, T2, TResult> func, object arg)
        {
            return (Func<T2, TResult>)Delegate.CreateDelegate(typeof(Func<T2, TResult>), arg, func.Method);
        }

        static void Main(string[] args)
        {
            Func<string, string[]> defSplit = StaticFunctions.Split;
            Func<string, string[]> customSplit = Bind1st(
                new Func<char[], string, string[]>(StaticFunctions.SplitCustom), new[] { '|' });

            Console.WriteLine(string.Join("-", defSplit("a b c")));
            Console.WriteLine(string.Join("-", customSplit("a|b|c")));
        }
    }
}


Вещь... Жаль только что даже в 4-м компиляторе не научили выводить типы генериков для делегатов, приходится писать new Func<char[], string, string[]>(StaticFunctions.SplitCustom).
Re[8]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.03.10 13:16
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Угу, только хотел сказать, что в результате все дружно начнут раскладывать функциональность классов на бихейворы, стратегии и прочие поведенческие паттерны. Фишка в том, что если стратегий много и они сложны, то удобнее всего их реализовывать с применением обычного ООП полиморфизма, с наследованием кода. А иначе все дойдет до маразма, т.е. потребует рекурсивно все раскладывать на простейшие "ячейки" функциональности, умножая многократно кол-во сущностей, которыми придется оперировать.


Обычно все таки юзкейсов не бесконечное количество и множество стратегий неплохо раскладывается на сравнительно небольшое количество групп, каждая из которых формирует определенную responsibility. Собственно, SRP как раз и придуман для того, чтобы не было подобных монстриков в коде.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[6]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 10.03.10 13:42
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>У меня просто не возникает обычно этой проблемы. Нет такого, чтобы класс являлся и тем, и вот этим, и другим, и третьим. Класс обычно наследует один интерфейс максимум. В таком виде его и тестировать и переиспользовать проще.

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

Плюс есть стандартные интерфейсы, реализацию которых хорошо бы было "примешивать" в класс по мере надобности.
Re[4]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 13:43
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Кстати, у тебя есть идея, как бы это могло синтаксически выглядеть в синтаксисе С++подобных языков? (типа Java/C#)


В том же D миксин обычный шаблон. Правда обычный шаблоном в D можно задавать не только классы и функции но и произвольные куски кода http://www.digitalmars.com/d/2.0/template.html
Re[2]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 10.03.10 13:44
Оценка:
Здравствуйте, LordMAD, Вы писали:

LMA>Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0). Аналогичную возможность обещали в c# 4.0

В С# 4.0 я что-то не нашел. Что касается дельфи — это хорошо. Для полного счастья надо бы иметь возможность перекрывать делегируемые методы, как в этом примере: здесь
Автор: 0x7be
Дата: 10.03.10
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 10.03.10 13:48
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, 0x7be, Вы писали:


V>Механизм реализации полиморфизма через плоскую таблицу виртуальных ф-ий делает такую реализацию затруднительной. Тут надо извращаться, для интерфейсов — своя таблица, для обычного наследования — своя. И если в дотнете, например, рантайм упорядочивает таблицу интерфейсов, то кто будет ее упорядочивать в нативных языках м/у независимыми модулями-dll?

Как он упорядочивает? Я так понял, что для каждого интерфейса, реализованного в классе, есть своя VMT.

V>Подобную технику, кстати, запросто можно сделать на платформе .Net, но нужен соотв. язык, который будет компилировать миксины например как value-type, для того, чтобы размещать их "в теле" класов, и нужна некая конструкция, которая будет указывать, какой интерфейс каким миксином обрабатывается (или даже с точностью до отдельных методов).

Либо использовать ссылки на объекты для делегации им интерфейсов.

V>Кстати, у тебя есть идея, как бы это могло синтаксически выглядеть в синтаксисе С++подобных языков? (типа Java/C#)

Я привел пример возможного синтаксиса делегации тут:
здесь
Автор: 0x7be
Дата: 10.03.10
Re[3]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.03.10 13:55
Оценка:
Здравствуйте, 0x7be, Вы писали:

LMA>>Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0). Аналогичную возможность обещали в c# 4.0

0>В С# 4.0 я что-то не нашел.

Нет, и я ни разу не слышал, чтобы кто то из тех, кто занимается разработкой шарпа, подобное обещал. На прямой вопрос о подерке агрегации на уровне синтаксиса я нормального ответа не получал ни разу. То бишь этого не планировалось, не планируется, и в C# 5 с хорошей вероятностью тоже не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[3]: [ООП] Хочу странного
От: Jack128  
Дата: 10.03.10 14:10
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


LMA>>Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0). Аналогичную возможность обещали в c# 4.0

0>Что касается дельфи — это хорошо. Для полного счастья надо бы иметь возможность перекрывать делегируемые методы, как в этом примере: здесь
Автор: 0x7be
Дата: 10.03.10

В дельфи можно и перекрывать.
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 10.03.10 14:13
Оценка:
Здравствуйте, Jack128, Вы писали:

0>>Что касается дельфи — это хорошо. Для полного счастья надо бы иметь возможность перекрывать делегируемые методы, как в этом примере: здесь
Автор: 0x7be
Дата: 10.03.10

J>В дельфи можно и перекрывать.
Можешь переписать пример по ссылке на Дельфи?
Re[5]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 14:45
Оценка:
Здравствуйте, FR, Вы писали:

FR>В том же D миксин обычный шаблон. Правда обычный шаблоном в D можно задавать не только классы и функции но и произвольные куски кода http://www.digitalmars.com/d/2.0/template.html


Судя по твои словам D замечательный язык. А ты сам то его используешь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 15:22
Оценка:
Здравствуйте, 0x7be, Вы писали:

YNT>>Можно пример( допустим, на некоем псевдокоде) работы описанного вами механизма? Или это утверждение что-то вроде "хорошо бы чтобы был мир во всем Мире"


0>Например так:


А на D примерно так:

interface IInterface1
{
  void F1();
}

interface IInterface2
{
  void F2();
  void F3();
}


mixin template A()
{
    void F1()
    {
    }
}


mixin template B()
{
    void F2()
    {
        
    }
    
    void F3()
    {
        
    }
    
}

class C : IInterface1, IInterface2
{
    mixin A!();
    mixin B!();
    
    void F3()
    {
        
    }
}
Re[8]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 10.03.10 15:25
Оценка:
Здравствуйте, FR, Вы писали:

FR>А на D примерно так:

FR>
...

Спасибо. А с делегированием пример можно описать?
Re[9]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 15:52
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Спасибо. А с делегированием пример можно описать?


В лоб как твой пример не получится, мешает то что D жестко контролирует чтобы в классе были определены все функции из интерфейсов, и поэтому делегирование не срабатывает, придется или писать методы заглушки или шаманить нечто на шаблонах.
Re[7]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:08
Оценка:
Здравствуйте, FR, Вы писали:

FR>На замечательные и красивые языки например D, Хаскель и Немерле (на этот только очень из далека) можно только любоваться.


На D и Хаскель, возможно. Nemerle довольно плотно используется на практике. Лично у меня уже где-то 5 проектов. Один из них — это конвертер документов Word в RSDN ML для нового шаблона. И не только я его использую.

ЗЫ

Собственно я почему-то так и подозревал, что на практике ты Ди не используешь. Вот ОКамл явно попользовал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 16:11
Оценка:
Здравствуйте, VladD2, Вы писали:


FR>>На замечательные и красивые языки например D, Хаскель и Немерле (на этот только очень из далека) можно только любоваться.


VD>На D и Хаскель, возможно. Nemerle довольно плотно используется на практике. Лично у меня уже где-то 5 проектов. Один из них — это конвертер документов Word в RSDN ML для нового шаблона. И не только я его использую.


Другие люди, не я пишут проекты и на хаскеле и на D.
Я бы не отказался писать на D если бы D 2 дошел да релиза, это очень хорошая замена C++.


VD>Собственно я почему-то так и подозревал, что на практике ты Ди не используешь. Вот ОКамл явно попользовал.


Так OCaml же некрасивый и корявый как верблюд
Re[8]: [ООП] Хочу странного
От: nikov США http://www.linkedin.com/in/nikov
Дата: 10.03.10 16:14
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>На замечательные и красивые языки например D, Хаскель и Немерле (на этот только очень из далека) можно только любоваться.


VD>На D и Хаскель, возможно. Nemerle довольно плотно используется на практике.


Haskell используется на практике побольше, чем Nemerle.
Re[9]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:44
Оценка:
Здравствуйте, FR, Вы писали:

FR>Другие люди, не я пишут проекты и на хаскеле и на D.


На хаскеле слышал. А на ди, нет.

FR>Я бы не отказался писать на D если бы D 2 дошел да релиза, это очень хорошая замена C++.


Сдается мне, ты так и прождешь до старости. Ведь за D 2 будет D 3...

VD>>Собственно я почему-то так и подозревал, что на практике ты Ди не используешь. Вот ОКамл явно попользовал.


FR>Так OCaml же некрасивый и корявый как верблюд


Это его главное достоинство?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 16:49
Оценка:
Здравствуйте, nikov, Вы писали:

N>Haskell используется на практике побольше, чем Nemerle.


Я на наших форумах знаю одно-двух человек кто на нем что-то более-менее серьезное пишет.
В прочем, не мудрено что пишут. Хаскелю в этом году исполняется 20 лет. Если бы за 20 лет на Хаскеле не было написано ни одного реального проекта, то что о нем вообще было бы говорить?

Немерлу официально пока что 0 лет. Посмотрим, что буде хотя бы лет через 5-7.

Потом, я не понял, что ты мне то отвечаешь? Отвечай FR-у. Это же его слова.

Меня интересует только почему он рекламирует одно, а пользуется другим. На мой взгляд — это выглядит по меньшей мере странно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 17:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>На хаскеле слышал. А на ди, нет.


Ну тут немало http://www.dsource.org/projects/
Плюс от знакомых игроделов слышал что уже есть небольшие коммерческие игры на нем.

FR>>Я бы не отказался писать на D если бы D 2 дошел да релиза, это очень хорошая замена C++.


VD>Сдается мне, ты так и прождешь до старости. Ведь за D 2 будет D 3...



Мне вполне достаточно возможностей D 2.

FR>>Так OCaml же некрасивый и корявый как верблюд


VD>Это его главное достоинство?


Конечно
Ну и то что у меня нет желания осиливать Хаскель
Re[10]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 17:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Потом, я не понял, что ты мне то отвечаешь? Отвечай FR-у. Это же его слова.


Ну я чисто свой субъективный взгляд привел.

VD>Меня интересует только почему он рекламирует одно, а пользуется другим. На мой взгляд — это выглядит по меньшей мере странно.


Ты это тоже не ему задавай а мне

Так здесь же принято рекламировать то чем не пользуешся, вот некоторые товарищи немерле так несколько лет рекламировали
Re[11]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 17:11
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ну тут немало http://www.dsource.org/projects/

FR>Плюс от знакомых игроделов слышал что уже есть небольшие коммерческие игры на нем.

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

FR>Мне вполне достаточно возможностей D 2.


Думаю, тебе и D 1 за глаза хватило бы. Просто ты ждешь какого-то светлого будущего.

FR>Конечно

FR>Ну и то что у меня нет желания осиливать Хаскель

Это да. Тут тебя очень многие поймут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 17:21
Оценка:
Здравствуйте, FR, Вы писали:

FR>Так здесь же принято рекламировать то чем не пользуешся, вот некоторые товарищи немерле так несколько лет рекламировали


Я что-то не припомню, чтобы Немерле рекламировали те кто на нем сами не писали. Сдается мне ты привераешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [ООП] Хочу странного
От: FR  
Дата: 10.03.10 17:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я что-то не припомню, чтобы Немерле рекламировали те кто на нем сами не писали. Сдается мне ты привераешь.


Так я тоже раньше постоянно писал на D, небольшие тестики и даже пару игрушечных утилиток, вот и практически все рекламщики Немерли примерно на этом же уровне и были несколько лет
Re[13]: [ООП] Хочу странного
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.10 17:50
Оценка:
Здравствуйте, FR, Вы писали:

FR>Так я тоже раньше постоянно писал на D, небольшие тестики и даже пару игрушечных утилиток, вот и практически все рекламщики Немерли примерно на этом же уровне и были несколько лет


У нас в конторе генератор отчетов
Автор: Владислав Чистяков aka VladD2
Дата: 17.07.08
написанный на немерле используется с 2008-го года и по сей день. До этого были созданы другие утилиты далеко не микроскопического размера (например, программа генерации метаифнормации для научного журнала). Они тоже используются по сей день. Вот только сегодня залил в БД РИНЦ (http://elibrary.ru/issues.asp?id=7639).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [ООП] Хочу странного
От: LordMAD Россия  
Дата: 10.03.10 18:10
Оценка:
Здравствуйте, 0x7be, Вы писали:

LMA>>Тот же delphi поддерживает implementing interfaces by delegation c 1998 года (с delphi 4.0). Аналогичную возможность обещали в c# 4.0

0>В С# 4.0 я что-то не нашел.

Где-то слышал — в памяти отложилось. Может и ошибаюсь — я за c# не особо внимательно слежу.

0>Что касается дельфи — это хорошо. Для полного счастья надо бы иметь возможность перекрывать делегируемые методы, как в этом примере:


Это делается так:

type
  IMyInterface = interface
    procedure P1;
    procedure P2;
  end;

  TMyImplClass = class (TInterfacedObject, IMyInterface)
    procedure P1;
    procedure P2;
  end;

  TMyClass = class(TObject, IMyInterface)
    FMyImplClass: TMyImplClass;
    property MyImplClass: TMyImplClass read FMyImplClass
      implements IMyInterface;
    procedure IMyInterface.P1 = MyP1;
    procedure MyP1;
  end;

  procedure TMyImplClass.P1;
  begin
    ShowMessage('TMyImplClass.P1');
  end;

  procedure TMyImplClass.P2;
  begin
    ShowMessage('TMyImplClass.P2');
  end;

  procedure TMyClass.MyP1;
  begin
    ShowMessage('TMyClass.MyP1');
  end;

procedure foo;
var
  MyClass: TMyClass;
  MyInterface: IMyInterface;
begin
  MyClass := TMyClass.Create;
  MyClass.FMyImplClass := TMyImplClass.Create;
  MyInterface := MyClass;
  MyInterface.P1;    // calls TMyClass.MyP1;
  MyInterface.P2;    // calls TImplClass.P2;
end;
Re[5]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 10.03.10 21:11
Оценка:
Здравствуйте, FR, Вы писали:

FR>В том же D миксин обычный шаблон. Правда обычный шаблоном в D можно задавать не только классы и функции но и произвольные куски кода http://www.digitalmars.com/d/2.0/template.html


Я может чего-то не понимаю, но способ определения кода как строковой константы меня немного беспокоит. А нельзя было без взятия в двойные кавычки?
Re[5]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 10.03.10 22:05
Оценка:
Здравствуйте, 0x7be, Вы писали:


V>>Механизм реализации полиморфизма через плоскую таблицу виртуальных ф-ий делает такую реализацию затруднительной. Тут надо извращаться, для интерфейсов — своя таблица, для обычного наследования — своя. И если в дотнете, например, рантайм упорядочивает таблицу интерфейсов, то кто будет ее упорядочивать в нативных языках м/у независимыми модулями-dll?

0>Как он упорядочивает? Я так понял, что для каждого интерфейса, реализованного в классе, есть своя VMT.

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

0>Либо использовать ссылки на объекты для делегации им интерфейсов.


Давай порассуждаем... с одной стороны это удобнее, ибо многие структурные и поведенчесские паттерны автоматически-декларативно получится описывать, с другой стороны — очередные +10 к косвенности и лишняя плата за абстракции. Но не в этом дело. Что делать, когда миксин, задействованный по ссылке, имеет null? Выкидывать исключение? Это же дыра дизайна, если методы начнут выкидывать исключения еще не выполнив ни одной своей строчки, типа как возможность вызова чистых виртуальных ф-ий в С++... Сдается мне, в промышленных языках на это не пойдут.

V>>Кстати, у тебя есть идея, как бы это могло синтаксически выглядеть в синтаксисе С++подобных языков? (типа Java/C#)

0>Я привел пример возможного синтаксиса делегации тут:
0>здесь
Автор: 0x7be
Дата: 10.03.10


Понятно, семантика страдает. Вот твоя запись:
IInterface1 = _a;

Такое ощущение, что мы привязываемся к экземпляру, а на самом деле мы привязываемся к ссылке на переменную-член, т.е. для явного обозначения семантики (как это принятно в .Net) надо было как-то так:
IInterface1 = ref _a;


Но и это мне не нравится тем, что декларация класса размазывается. Я не зря задал вопрос про синтаксис, ибо семантика миксинов, генеренных как часть компиляции, не может быть столь же недетерминированной, как ручное делегирование. В предыдущем абзаце уже высказал соображения, что вряд ли миксин может быть доступен для произвольной замены, а то легко можно null получить. Т.е. мне кажется, что миксин должен быть неотъемлимой частью типа, так же как является неотъемлимой частью типа таблица виртуальных ф-ий. И синтаксис здесь мог бы быть аналогичным (пока еще непонятно на каких скобках или разделителях остановиться, но не суть):

interface IInterface1
{
  void F1();
}

interface IInterface2
{
  void F2();
  void F3();
}

class A // необязательно : IInterface1
{}

class B // пусть проверяется во время инстанциирования : IInterface2
        // аналогично с добавлением обычных интерфейсов к классу-наследнику без добавления методов
{}

class C : IInterface1|A, IInterface2|B
{
  // Явная реализация метода, перекрывает делегирование этого метода, описанное выше.
  void IInterface2.F3()
  {  }

  // Неявная, наверно, тоже :)
  public void F2()
  {}
  
  // доступ к миксинам-кирпичикам, конструктор
  public C(int arg1, string arg2) 
    : this.A(arg1), this.B(arg2) 
  {}

  // доступ к миксинам-кирпичикам, тела методов
  public double Prop {
    get { return A.Prop * 0.1; }
    set { A.Prop = value / 0.1; }
  }
}


Но и это все такая ерунда по сравнению с еще одним вопросом (I1, I2, I3, In — интерфейсы, "->" наследует):
что делать, если I2->I1, I3->I1, а затем у нас реализация на миксинах class A->I2|A,I3|B? Приплыли, сушим весла? Причем, сушим весла мы и в твоей концепции и в моей. В С++ такое разруливается, ибо таблицы интерфейсов нет, есть участок в одной таблице виртуальный ф-ий, и мы можем явно задать смещение на этом участке через приведение к одному из базовых типов в случае такого МН, а в дотнете факт реализации интерфейса для каждого типа — уникальный, т.е. мы наткнулись на фундаментальное ограничение.
Re[7]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 11.03.10 03:58
Оценка:
Здравствуйте, FR, Вы писали:

FR>Это только один из способов и по замыслу создателей языка он предназначен только для построения EDSL.

FR>Обычные же миксины же определятся без всяких скобок как простые шаблоны http://www.digitalmars.com/d/2.0/template-mixin.html

Вообще, давненько я на ВD не смотрел, в плане миксинов прикольно у них все выходит. И глобальные миксины — в этом что-то есть... как хорошее, так и не очень.
(Ищи потом, в какую переменную чего пишется).
Re[6]: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 04:13
Оценка:
Здравствуйте, vdimas, Вы писали:


V>Да, т.е. таблица не плоская, а с 1-м уровнем вложенности. А упорядочивает тем, что тип некоего интерфейса один для всех реализующих его методов, и рантайм знает, где искать эту таблицу для любого такого типа. В то же самое время отдельные DLL понятие могут не иметь, где в типах из других DLL искать таблицу того же самого инттерфейса, ибо в том же С++ типы существуют только во время компляции. Ну или же есть RTTI, но на этой технике далеко не уедешь (в плане эффективности).


В OCaml это сделано как хеш таблица по сигнатуре метода http://lj.rossia.org/community/programming/920.html
Re[7]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 11.03.10 13:21
Оценка:
Здравствуйте, FR, Вы писали:


FR>В OCaml это сделано как хеш таблица по сигнатуре метода http://lj.rossia.org/community/programming/920.html


Но это что-то вроде RTTI, т.е. эффективность вызова зависит от эффективности реализации хранения метаданных, и никак в 3 ассемблерные инструкции не укладывается.
Re[2]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 11.03.10 13:47
Оценка:
Здравствуйте, FR, Вы писали:

0>>Что если принципиально разделить эти вещи? Абстракция через обобщение в чистом виде есть во многих языка в виде интерфейсов, которые, кстати, поддерживают множественное наследование даже там, где классы поддерживают только единичное. Повторное использование кода тоже возможно другим способом — через композицию объектов. Единственное, чего нет — это синтаксически хорошо оформленное делегирование реализации интерфейса/части интерфейса композитам, из которых составлен класс-композиция. Но это не сложный аспект, который можно реализовать.


FR>Почитай еще как устроенны классы в OCaml http://lj.rossia.org/community/programming/704.html в общем проблема решается за счет того что объект опознается только по сигнатуре метода (утиная типизация) а наследование чистый синтаксический сахар.


В принципе, не суть важно как оно внутре устроено, возможен ли строготипизированный контроль со стороны компилятора? Или оно "чистое утиное", как в скриптовых?
Re[8]: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 13:54
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Но это что-то вроде RTTI, т.е. эффективность вызова зависит от эффективности реализации хранения метаданных, и никак в 3 ассемблерные инструкции не укладывается.


Это да, хотя скорее недо-RTTI и в 5 — 10 ассемблерных инструкций уже укладывается.
Re[3]: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 14:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>В принципе, не суть важно как оно внутре устроено, возможен ли строготипизированный контроль со стороны компилятора? Или оно "чистое утиное", как в скриптовых?


Оно чисто утиное в том смысле метод определяется только по сигнатуре, то есть функция работающая с объектом будет работать с любым объектами у которых есть методы с сигнатурами совпадающими с используемыми в данной функции. Но при этом в отличии от скриптовых во всем остальном остается жесткая статическая типизация.
Re[9]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 11.03.10 16:36
Оценка:
Здравствуйте, FR, Вы писали:

FR>Это да, хотя скорее недо-RTTI и в 5 — 10 ассемблерных инструкций уже укладывается.


А как в 5-10 инструкций найти в хэш-таблице сигнатуру метода, скажем, с двумя параметрами?
Re[7]: [ООП] Хочу странного
От: Silver_s Ниоткуда  
Дата: 11.03.10 17:03
Оценка:
Здравствуйте, 0x7be, Вы писали:

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

0>Ладно, давай представим, это не стандартный интерфейс. Как бы ты тогда выкрутился с extension-методами?

Extention методы решают только одну проблему — снимают рябь в глазах
o.F1().F2() вместо Cl.F2(Cl.F1(o))
Re[9]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 11.03.10 17:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Обычно все таки юзкейсов не бесконечное количество и множество стратегий неплохо раскладывается на сравнительно небольшое количество групп, каждая из которых формирует определенную responsibility.


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

Т.е. просто заметил из своей практики интересную вещь: хотя некий целевой "сложный" класс мы собираем практически без наследования реализаций, группы "кирпичиков"-стратегий, traits и т.д. удобно делать с применением техники наследования той самой реализации. В принципе, неудивительно, коль некие требования, потенциально наводящие друг на друга нежелательные эффекты, были изолированы друг от друга.
Re[8]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 11.03.10 17:24
Оценка:
Здравствуйте, Silver_s, Вы писали:

S_>Extention методы решают только одну проблему — снимают рябь в глазах

S_>o.F1().F2() вместо Cl.F2(Cl.F1(o))

угу, и перечисление примененых ф-ий идет слева-направо, сверху вниз.
Re[10]: [ООП] Хочу странного
От: FR  
Дата: 11.03.10 17:47
Оценка:
Здравствуйте, vdimas, Вы писали:

FR>>Это да, хотя скорее недо-RTTI и в 5 — 10 ассемблерных инструкций уже укладывается.


V>А как в 5-10 инструкций найти в хэш-таблице сигнатуру метода, скажем, с двумя параметрами?


А поиск от числа параметров не зависит, нумерация всех методов сквозная, номера присваиваются при инициализации рантайма.
Да и хеш громко сказано по сути там выборка из таблицы.
Re[12]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.03.10 04:50
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Конечно, большая разница. Программирование на контрактах — это компонентно-ориентированное.


При чем тут программирование на контрактах? Знакомое слово увидел? Контракт — базовое понятие ООП (и не только ООП).

V>Опять много наспамил, сорри


Не переживай, я все, не относящееся к делу, поскипал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[13]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 12.03.10 09:16
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>Конечно, большая разница. Программирование на контрактах — это компонентно-ориентированное.


AVK>При чем тут программирование на контрактах? Знакомое слово увидел? Контракт — базовое понятие ООП (и не только ООП).



Приплыли. Вернемся чуть назад.

Да, ты часто применяешь термин "контракт", но пора внести ясность. Касательно ООП ты вроде настаивал на исключение наследования реализаций, но применения только "контрактов", вот мне и показалось, что у тебя получается разновидность "контрактного программирования". Немного недоделанная, потому как в чистом виде в C# контрактное программирование не поддерживается... (есть примочка от MS — http://research.microsoft.com/en-us/projects/contracts/ — попытка восполнить пробел).

В общем, пора называть вещи своими именами. Сущность interface из дотнета до "контракта" в терминах контрактного программирования не дотягивает, называть их контрактами — это создавать путаницу, т.к. отсылает нас к совсем другой известной парадигме. В классическом ООП публичный АПИ типов зовется "интерфейсом", но выделенная отдельно эта сущность в .Net не стала сама по себе полноценным "контрактом". Так что, хоть мы и понимаем прекрасно, что ты имеешь ввиду, называя интерфейсы "контрактами", но это немного вольное обращение с терминами. Поэтому да, "знакомое слово увидел".

ИМХО, вряд ли я ошибся, когда предположил, что в условиях C# твой способ более всего похож по технике на компонентно-ориентированное программирование. Даже если ты и не стремишься следовать букве этой парадигмы, она у тебя выходит автоматически. Ну и опять же, техника миксинов — это оно и есть, т.е. наиболее удобный инструмент для этого подхода. Напоследок, контрактному программированию вообще пофиг — есть наследование реализаций, или нет, в отличие от компонентного подхода, который ограничивает применимость техники ООП (или любой другой парадигмы) рамками одного компонента.

------------
Почему я стремлюсь развесить "ярлыки" на подходы? Потому как информации здесь в форуме мы обычно даем мало, но каждый из подходов имеет ее гораздо больше в своем описании, т.е. ссылка на известные парадигмы — это один из способов прояснить свою позицию... Ты этого не делаешь, я пытаюсь делать это за тебя, т.к. полного описания твоего подхода мы вряд ли дождемся.
Re[14]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.03.10 13:13
Оценка:
Здравствуйте, vdimas, Вы писали:

V>В общем, пора называть вещи своими именами. Сущность interface из дотнета до "контракта" в терминах контрактного программирования не дотягивает


При чем тут контрактное программирование?

V>, называть их контрактами — это создавать путаницу


Путанницу создаешь ты, когда приплетаешь вещи, к разговору вообще не имеющие никакого отношения. И когда сильно загаживаешь свои сообщения абсолютно левыми философствованиями. Тебя читать невозможно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[15]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 12.03.10 18:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:


V>>В общем, пора называть вещи своими именами. Сущность interface из дотнета до "контракта" в терминах контрактного программирования не дотягивает


AVK>При чем тут контрактное программирование?


V>>, называть их контрактами — это создавать путаницу


AVK>Путанницу создаешь ты, когда приплетаешь вещи, к разговору вообще не имеющие никакого отношения. И когда сильно загаживаешь свои сообщения абсолютно левыми философствованиями. Тебя читать невозможно.


Ну накопилось... Ты все время повторяешь "контракты, контракты", хотелось ясности.
Re[8]: [ООП] Хочу странного
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.10 19:18
Оценка:
Здравствуйте, Silver_s, Вы писали:

S_>Здравствуйте, 0x7be, Вы писали:


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

0>>Ладно, давай представим, это не стандартный интерфейс. Как бы ты тогда выкрутился с extension-методами?

S_>Extention методы решают только одну проблему — снимают рябь в глазах

S_>o.F1().F2() вместо Cl.F2(Cl.F1(o))

когда таких вызовов становится по 5-10 штук, то из зп этой ряби приходится городить вагоны кода
Re[3]: [ООП] Хочу странного
От: igna Россия  
Дата: 13.03.10 08:29
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Если она старая и очевидная, то почему в мэйнстриме она не нашла своего места?


Так ведь для того чтобы не использовать наследование реализации, никаких дополнительных фич в имеющиеся языки добавлять не надо; то есть, чтобы определить, нашла или не нашла эта идея место, нужно смотреть программы, а не языки. C++ например позволяет наследовать реализацию, но STL этой возможностью не пользуется.
Re[4]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 13.03.10 08:34
Оценка:
Здравствуйте, igna, Вы писали:

I>Так ведь для того чтобы не использовать наследование реализации, никаких дополнительных фич в имеющиеся языки добавлять не надо; то есть, чтобы определить, нашла или не нашла эта идея место, нужно смотреть программы, а не языки. C++ например позволяет наследовать реализацию, но STL этой возможностью не пользуется.

Не совсем. ЕМНИП, они применяют наследование реализации в случае с trait-классами, что представляет собой mixin-style в чистом виде. Что касается текущих возможностей языков — я этого не отрицаю. Речь идет скорее о распространении самой идеи и наличии в языках специальной поддержки, т.е. синтаксического сахара для такого стиля программирования.
Re[5]: [ООП] Хочу странного
От: igna Россия  
Дата: 13.03.10 10:30
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>ЕМНИП, они применяют наследование реализации в случае с trait-классами...


А именно? Наследование от iterator_traits? Так там весьма своеобразная "реализация", состоящая исключительно из определений типов. Даже если наследование от iterator_traits можно назвать "повторным использованием кода", в таком виде оно не имеет недостатков присущих наследованию реализации в общем виде. Этот антипаттерн в STL вообще не используется.
Re[11]: [ООП] Хочу странного
От: LaPerouse  
Дата: 13.03.10 10:47
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


V>>В этом-то и соль. Я из своего личного опыта высказался о том (может недоуточнил), что каждую отдельную группу стратегий удобно реализовать именно через наследование поведения.


AVK>Удобство только сомнительное. Я почему то на практике вижу от наследования реализации море проблем и практически полное отсутствие пользы.


Очевидная польза в том, что при наследовании реализации потомок автоматически поддерживает интерфейс предка. Точнее, это будет пользой не всегда, а только тогда, когда <Интерфейс_предка_1> + <Интерфейс_предка_2> принадлежит <Интерфейс_наследника>. Но как раз таких случаев много бывает. При делегировании придется вколачивать методы совокупного интерфейса <Интерфейс_предка_1> + <Интерфейс_предка_2> и делать из них тупое делегирование к объектам-делегаторам (или как они там называются).

Если правило
<Интерфейс_предка_1> + <Интерфейс_предка_2> принадлежит <Интерфейс_наследника>
не выполняется, тогда нужно выполнять делегирование, реализую в классе лишь те методы совокупного интерфейса <Интерфейс_предка_1> + <Интерфейс_предка_2>, которые являются частью <Интерфейс_наследника>.

Минус наследования реализации в том, что если в будущем потребуется исключить из <Интерфейс_наследника> метод, принадлежащий сопокупному интерфейсу <Интерфейс_предка_1> + <Интерфейс_предка_2>, то сделать это будет не так просто. То есть идет завязка на иерархию наследования.

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


А это не только в программировании так. Проблема в том, что ни в одной дисциплине нет четко формализованных знаний. Человечество накопило огромный багаж знаний, а способ хранения этих знаний за последние 20 веков не изменился. Знания должны храниться в виде, пригодном для стандартизации. Но текст малопригоден для этого. Проблему может решить WEB 3.0 и всеобщая централизация знаний человечества в единую базу знаний (семантическую сеть например).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.03.10 13:49
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP> При делегировании придется вколачивать методы совокупного интерфейса <Интерфейс_предка_1> + <Интерфейс_предка_2> и делать из них тупое делегирование к объектам-делегаторам (или как они там называются).


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

LP>А это не только в программировании так. Проблема в том, что ни в одной дисциплине нет четко формализованных знаний.


Дело не в формализации, а в откровенно неверных предпосылках.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[13]: [ООП] Хочу странного
От: LaPerouse  
Дата: 13.03.10 14:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


LP>> При делегировании придется вколачивать методы совокупного интерфейса <Интерфейс_предка_1> + <Интерфейс_предка_2> и делать из них тупое делегирование к объектам-делегаторам (или как они там называются).


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


А, тогда я неправильно понял

AVK>До наследования только контракта мейнстрим, слава богу, дошел, дело за наследованием реализации без наследования контракта.


Такое можно делать и без поддержки в языке "наследования реализации без интерфейсов". Для этого всю реализацию нужно содержать в приватных для модуля классах, функциональность предоставлять через публичные интерфейсы, объекты создавать через фабрику (потому как сами классы с реализацией не видны). То есть классика по сути. И вот тут множественное наследование очень бы пригодилось. Оно конечно костылем было бы, но раз не дали миксины, зачем было убирать его из языка (я про java и с#)?

LP>>А это не только в программировании так. Проблема в том, что ни в одной дисциплине нет четко формализованных знаний.


AVK>Дело не в формализации, а в откровенно неверных предпосылках.


А они берутся из-за отсутствия формализации. Нет стандартизованных знаний, отсюда все проблемы.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[14]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.03.10 16:57
Оценка:
Здравствуйте, LaPerouse, Вы писали:

AVK>>До наследования только контракта мейнстрим, слава богу, дошел, дело за наследованием реализации без наследования контракта.


LP>Такое можно делать и без поддержки в языке "наследования реализации без интерфейсов".


Можно. Делегированием. Но уж очень неудобно.

AVK>>Дело не в формализации, а в откровенно неверных предпосылках.


LP>А они берутся из-за отсутствия формализации.


Крайне сомнительно. ЯП это не явление природы, естественнонаучные методы к нему в полном объеме неприменимы. ЯП, в виду своего назначения (обеспечение взаимодействия машинной логики с моском человека) в немалой степени определяется нематериальными аспектами культуры, например образом мышления программиста. И эти самые аспекты с формализацией дружат очень плохо. Можно загнать программизм в рамки формализма, но результатом будет жуткая неудобоваримость, как, к примеру, в квантовой физике, когда сильно упрощенные модели описываются невероятно трудным в понимании каскадом высшей математики. Современного размера и сложности программу так не напишешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
AVK Blog
Re[6]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 13.03.10 18:38
Оценка:
Здравствуйте, igna, Вы писали:

I>А именно? Наследование от iterator_traits? Так там весьма своеобразная "реализация", состоящая исключительно из определений типов. Даже если наследование от iterator_traits можно назвать "повторным использованием кода", в таком виде оно не имеет недостатков присущих наследованию реализации в общем виде. Этот антипаттерн в STL вообще не используется.

В одной из корпоративных библиотек видел фантазию на тему бустового shared_ptr, где в качестве trait`а передавался класс, реализующий блокировку. Я такой сценарий имел в виду.
Re[15]: [ООП] Хочу странного
От: LaPerouse  
Дата: 13.03.10 22:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>До наследования только контракта мейнстрим, слава богу, дошел, дело за наследованием реализации без наследования контракта.

LP>>Такое можно делать и без поддержки в языке "наследования реализации без интерфейсов".
AVK>Можно. Делегированием. Но уж очень неудобно.

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

AVK>>>Дело не в формализации, а в откровенно неверных предпосылках.

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

Так ведь я не предлагаю формализовать ЯП, я предлагаю формализовать знания о методиках программирования. На нашем примере: мы имеем конкретную проблему — отсутствует понимание того, в каких случаях надо использовать наследование реализации, в каких — контракта. Происхождение проблемы: большинство авторов учебников не уделяют должного внимания этому аспекту. Почему? Причина банальна: мало кто из авторов обладает по-настоящему экспертными знаниями в той области, о которой пишет. Действительно ценные книги и статьи, написанные профессионалами, теряются среди кучи всяких "Освой Java за 21 день". Проблема может иметь решение — стандартизация экспертных знаний различных предметных областей путем создания семантической базы знаний (стандартизация знаний в текстовом виде невозможна). Все средства на сегодня уже существуют — детально разработаны форматы хранения данных (RDF+OWL), созданы эффективные хранилища (Oracle 11g, jena store), существуют проработанные языки запросов (RDFQL, SPARQL). Предстоит многолетняя работа по созданию и стандартизации словарей и онтологий, эта работа уже идет. К сожалению, идет очень медленно, поскольку производительные процессы кап. общества завязаны на прибыль, а прибыль разработчикам онтологий если и светит, то не в ближайшем будущем. Онтологии создаются в основном для своих текущих нужд. Но даже капитализм рано или поздно таки доползет до создания публичных стандартизованных онтологий и баз знаний.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[7]: [ООП] Хочу странного
От: igna Россия  
Дата: 14.03.10 10:08
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>В одной из корпоративных библиотек видел фантазию на тему бустового shared_ptr, где в качестве trait`а передавался класс, реализующий блокировку. Я такой сценарий имел в виду.


Ну так это не в STL.
Re[8]: [ООП] Хочу странного
От: 0x7be СССР  
Дата: 14.03.10 15:02
Оценка:
Здравствуйте, igna, Вы писали:

0>>В одной из корпоративных библиотек видел фантазию на тему бустового shared_ptr, где в качестве trait`а передавался класс, реализующий блокировку. Я такой сценарий имел в виду.

I>Ну так это не в STL.
Виноват, ввёл в заблуждение
Но идея, я думаю, понятна.
Re[16]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.03.10 15:48
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Или множественным наследованием.


А МН даже с приватным наследованием тянет за собой слишком много связей.

LP>Так ведь я не предлагаю формализовать ЯП, я предлагаю формализовать знания о методиках программирования.


Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?

LP>Причина банальна: мало кто из авторов обладает по-настоящему экспертными знаниями в той области


Не не не. Либо экспертная оценка, либо формализация. Это принципиально разные методы.

LP>, о которой пишет. Действительно ценные книги и статьи, написанные профессионалами, теряются среди кучи всяких "Освой Java за 21 день".


Да не теряются они. Проблема куда глубже. В качестве примера — безобразную и безграмотную книгу Троелсена по дотнету здесь в форумах советует чуть ли не каждый второй. Что то ведь ее выделило среди тонн таких же безграмотных книг?

LP> Проблема может иметь решение — стандартизация экспертных знаний различных предметных областей путем создания семантической базы знаний


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

LP>Предстоит многолетняя работа по созданию и стандартизации словарей и онтологий, эта работа уже идет.


Если она уже идет — где выхлоп?

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


Ага, то есть пользы ноль целых, ноль десятых.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
AVK Blog
Re[17]: [ООП] Хочу странного
От: LaPerouse  
Дата: 15.03.10 13:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


LP>>Или множественным наследованием.

AVK>А МН даже с приватным наследованием тянет за собой слишком много связей.

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

Вот что у нас есть:
public interface Interface1
{
void foo1();
void bar1();
}

public interface Interface2
{
void foo2();
void bar2();
}

public class Impl1 implements Interface1
{
public void foo1() {/*foo1 impl*/}
public void bar1() {/*bar1 impl*/}
}

public class Impl2 implements Interface2
{
public void foo2() {/*foo2 impl*/}
public void bar2() {/*bar2 impl*/}
}


Множественное наследование, если бы оно было в java:
public class Impl extends Impl1, Impl2
{
}


В результате имеем, что Impl наследует реализации foo1, bar1, foo2, bar2 и интерфейсы Interface1 и Interface2. То есть наследует и интерфейс, и реализацию. Как этого избежать?

Вариант 1 — делегирование:
public class Impl
{
Impl1 impl1;
Impl2 impl2;
}


Теперь мы можем использовать реализацию impl1 и impl2 без наследования интерфейсов Interface1 и Interface2. Однако задача решена плохо. Если нам нужно к примеру, чтобы Impl реализовал интерфейс Interface1, нам нужно писать делегирующий код:

public class Impl implements Interface1
{
Impl1 impl1;
Impl2 impl2;

public void foo1() {impl1.foo()}
public void bar1() {impl2.bar()}
}

В этом плане делгирование не самый лучший вариант. Давай попробуем вернуться к варианту с множественным наследованием. Так ли он плох? Проблема в том, что Impl помимо реализации Impl1, Impl2 наследует их интерфейсы. Чего нам совершенно не нужно. Как этого избежать? Решение — работать с Impl не напрямую, а исключительно через некоторый публичный интерфейс Interface (сделав его невидным извне модуля например). Отнаследовав Interface от Interface1, переписываем пример выше:

public Interface extends Interface1
{
}

class Impl extends Impl1, Impl2 implements Interface
{
}


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

Таким образом, множественное наследование при правильном его применении способно помочь в отделении наследования реализации от наследования интерфейсов, причем эффективнее, чем делегирование.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[17]: [ООП] Хочу странного
От: LaPerouse  
Дата: 15.03.10 14:36
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?


Эти — не нужно.

LP>>Причина банальна: мало кто из авторов обладает по-настоящему экспертными знаниями в той области

AVK>Не не не. Либо экспертная оценка, либо формализация. Это принципиально разные методы.

Экспертная оценка — это из другой оперы.
Формализация знаний должна производиться экспертами. См. экспертные системы.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[18]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.03.10 16:30
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


Только это уже не совсем МН будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
AVK Blog
Re[19]: [ООП] Хочу странного
От: LaPerouse  
Дата: 15.03.10 18:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


AVK>Только это уже не совсем МН будет.


Используется МН для наследования реализации.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: [ООП] Хочу странного
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.03.10 18:05
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Используется МН для наследования реализации.


Только вот побочные эффекты от наследования интерфейса все равно остаются, хотя бы и внутри модуля.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
AVK Blog
Re[21]: [ООП] Хочу странного
От: LaPerouse  
Дата: 15.03.10 18:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


LP>>Используется МН для наследования реализации.


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


У всего есть свои недостатки.
Разработчик модуля знает про свой модуль и сможет воздержаться от неподобающего использования своих классов.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: [ООП] Хочу странного
От: Silver_s Ниоткуда  
Дата: 15.03.10 19:21
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Ты кажется подумал, что я предлагаю сделать какой-то ИИ для атвоматического программирования. Ничего подобного. Возьми любой учебник по программированию, выдели ключевые понятия, задай отношения между ними (субъет-предикат-объект), расставь семантические ссылки — вот пример базы знаний. Только на базе одного учебника и одного специалиста база знаний получится убогой. А теперь представь, что то же самое делается на обширном материале трудом десятков тысяч специалистов — получим полноценную базу знаний для соответствующей предметной области.


Что потом с этой базой делать? Как справочник-учебник по программированию?
Слышал какая-то контора уже лет 15 вбивает в продукционную систеу правила из всех областей. Точно не помню, но порядка нескольких миллионов правил уже. Какая-то чатилка есть в инете с этой системой. Но такие системы имеют отношение скорее не к промышленности, а к индустрии развлечений.
Re[21]: [ООП] Хочу странного
От: LaPerouse  
Дата: 15.03.10 20:51
Оценка:
Здравствуйте, Silver_s, Вы писали:

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


LP>>Ты кажется подумал, что я предлагаю сделать какой-то ИИ для атвоматического программирования. Ничего подобного. Возьми любой учебник по программированию, выдели ключевые понятия, задай отношения между ними (субъет-предикат-объект), расставь семантические ссылки — вот пример базы знаний. Только на базе одного учебника и одного специалиста база знаний получится убогой. А теперь представь, что то же самое делается на обширном материале трудом десятков тысяч специалистов — получим полноценную базу знаний для соответствующей предметной области.


S_> Что потом с этой базой делать? Как справочник-учебник по программированию?


Использовать как более хорошую википедию. С типизированными ссылками. С возможностью выполнять сложные запросы. Например: найти список языков программирования, поддерживающих множественное наследование, выпущенных после 1991 года. Но самое главное — иметь надежный стандартизованный источник знаний.

См. например Semantik Wiki

S_>Слышал какая-то контора уже лет 15 вбивает в продукционную систеу правила из всех областей. Точно не помню, но порядка нескольких миллионов правил уже. Какая-то чатилка есть в инете с этой системой. Но такие системы имеют отношение скорее не к промышленности, а к индустрии развлечений.


Тратить труд тысяч квалифицированных специалистов ради чатилки? Бред. Это явно не цель этого проекта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[17]: [ООП] Хочу странного
От: vdimas Россия  
Дата: 16.03.10 08:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А МН даже с приватным наследованием тянет за собой слишком много связей.


Есть такая практика — не использовать МН для создания базовых классов, а только лишь для создания самого последнего наследника. ATL и STL используют эту же практику, вполне надежно выходит.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.