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

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

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

D>Здравствуйте, c-smile, Вы писали:

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

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

CS>>>>Норально решается. mixin's резолвятся во время последней фазы
CS>>>>компиляции. Поэтому такое вот работает:

VD>>>То есть никакого контроля до использования, и в добавок прямое обращение к именам из внешних классов?

CS>>Данная DisabledImpl() в том виде как объявлена может быть применена
CS>>к чему либо имеющему _disabled переменную в области применения.

CS>>Иначе — ошибка компиляции.

D>Так вот применишь ты, например, mixin DisabledImpl к чему-то, что не имеет переменной _disabled и будешь гадать, отчего же компиляция свалилась. DisabledImpl ведь к своему окружению особые требования предъявляет, только вот требования эти не локализованы, а размазаны по коду. Моменты и места, где обнаруживаются ошибки компиляции не равнозначны: я бы предпочел увидеть ошибку компиляции в месте, где DisabledImpl к чему-то применяется с сообщением, что mixin нельзя к этому применить, чем сообщение о том, что некая переменная _disabled (непонятно зачем нужная) не была найдена в DisabledImpl.

Ошибка сообщаемая компилятором двойная в этом случае:

.\harmonia\ui\controls\common.d(37): undefined identifier _disabled
.\harmonia\ui\controls\common.d(38): undefined identifier _disabled
.\harmonia\ui\controls\editbox.d(115): template instance cannot resolve forward reference

template DisabledImpl()
{
  bool disabled() { return _disabled; } // line 37
  bool disabled(bool onoff) { _disabled = onoff; return disabled(); } // line 38
}

editbox.d(115) — это в классе вставки mixin DisabledImpl!();

Если нужно что-то свое сообщить то можно наверное так:

template DisabledImpl()
{
  static if ( is (_disabled == bool))
  {
    bool disabled() { return _disabled; }
    bool disabled(bool onoff) { _disabled = onoff; return disabled(); }
  }
  else
    pragma (msg, "Warning: cannot find _disabled field of type bool");

}

На самом деле templates в D это вешь.

Don Clugston даже умудрился сделать compile time regexp.

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


E>Так может эта... Может глянуть что именно компилятор D в таком случае говорит? Может он говорит, что DisabledImpl не может быть подмешен к классу из-за того, что в классе нет _disabled, который нужен DisabledImpl?

E>Я не пользовался D, но есть подозрение, что подобную диагностику он должен нормально выдавать.

Так оно и есть — нормальное сообщение.

E>

---

E>Пользуясь случаем хочу задать вопрос c-smile о D (прошу прощения за оффтопик, по почте с c-smile у меня не получилось связаться ).

Как так?

E>Андрей, вообще видны какие нибудь перспективы появления стабильной версии языка? А то смотришь его ChangeLog -- все время что-то меняется. Да и в списке того, что хотелось иметь, еще есть пункты. Как то стремно связываться с языком и писать код с сознанием того, что после очередного изменения в языке часть кода придется переписывать.

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

Мне лично нужен механизм аналогичный const в С++.
Без него как-то сложно большой проект запускать...

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

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

D>>Я здесь более акцентировал внимание на то, что у mixin'а лучше было бы иметь четко определенный контракт, который, в свою очередь, мог бы помочь обнаружить проблемы на более ранних стадиях компиляции и, возможно, с более понятной диагностикой.
D>+ (что не менее важно) помог бы программисту понять к чему можно применять данный mixin, а к чему нет, еще до того, как он получит ошибку компиляции.

Контракт это что? Фактически это описание параметров для мета функции...
Ну так и пишем в D

template DisabledImpl(alias disabledMember:bool = _disabled)
{
  bool disabled() { return disabledMember; }
  bool disabled(bool onoff) { disabledMember = onoff; return disabled(); }
}

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

WR>>Если выражаться общими словами, то можно сказать что множественное наследование рулит при описании ортогональной функциональности. Приведу пример из своей практики:
WR>>

WR>>class LIKEVIEW_API Document : // Класс - Точка сборки
WR>>    public Object<LV_IDCLASS_DOCUMENT_BASE, Document>, // Объект создаваемый фабрикой
WR>>    public RefCounter,    // счётчик ссылок
WR>>    public Widget,        // базовый элемент ГУИ
WR>>    public Properties,    // контейнер свойств
WR>>    public Shape,         // фигура ГДИ
WR>>    public IdGenerator,   // генератор идентификаторов для сериализации связей
WR>>    public Port,          // узел графа схемы
WR>>    public Link,          // связь графа схемы
WR>>    public Executor       // исполнитель действий
WR>>{
WR>>// ...
WR>>

VD>RefCounter в лес за недадобностью.

Осторожнее на виражах. RefCounter может быть нужен совсем не только для контроля жизненного цикла объекта. Могут быть и "сугубо прикладные" задачи. Например, оптимизация подсчётов для связей m:n.

Ergo. RefCounter — вернуть. Кстати, он может быть на-а-амного сложнее, чем банальный m_refs++/m_ref--. Ещё похожий пример с наследованием от узлов списков здесь приводили.

VD>Document не имеет быть права контролом (Widget-ом) с точки зрения дизайна, в прочем как и фигурой (Shape) и исполнителем действий (Executor).

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

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

VD>И того при нормальном дизайте этот класс будет вглядеть как-то так:

Э... осталось добавить вакуум и сферообразие.

VD>

VD>// Объект создаваемый фабрикой
VD>[ClassFabric(X)]
VD>class Document : SchemaNode
VD>{
VD>  Properties Properties { get { Properties(); } }
VD>}
VD>

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

Вывод о поспешно сделанном выводе ещё более очевиден.

WR>>Если последовать традиционным путём полиморфного разделения функционала, то получился бы комбинаторный взрыв классов.
VD>Не... получился бы хороший дизайн намного более подходящий для дольнейшего развития.

WoldemaR совершенно прав по поводу комбинаторного взрыва при исходной полиморфной декомпозиции. Тому косвенным подтверждением нагромождение коллекций в Java. Второе подтверждение — многократно осуждавшийся паттерн Visitor/Visited.

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

K>>А это пример значит неконкретный?
VD>Это вообще не пример. Пример подразумевает объяснение целей и решений. Здесь же не ясно что и зачем.



K>>Пример вполне тривиальный и жизненный. Грубо говоря обьект разделяется м-ду двумя документами. Один — модель, владелец всех обьектов, через которую идет вся работа с данными, другой документ 3-д сцены,
VD>О как. Мы противопоставляем модль и документ. А что же тогда такое документ как не модель?

В контексте MVC — одно и то же. В конкретных случаях этот термин может иметь любую семантику. Всё зависит от условий. Могут быть и документы контроллера.

K>> который юзается для отрисовки и UI манипуляций. т.е. не классичесский doc — view, а doc — proxy_doc — view. Где doc — модель, proxy_doc — сцена3д, view — окно_сцены.
VD>Нда. Эту уже на концептуальном уровне выглядит страшно. Раньше все было просо "модель-представление-контроллер". Как разновидность интеграция контроллера в представление. Прокси использовался для создания переходника интерфейса. А тут прям новые концепции. Вот только один вопрос. А оно надо?

А что тут не так? doc содержит исходные сущности, proxy_doc — базовое 3D-отображение, view — проекцию с заданными параметрами. Терминологически не совсем корректно, но не более того.

K>> Преимущества такого подхода очевидны.
VD>Кому, простите?

Мне. Достаточно?

K>> Модель — крайне ветвиста и наворочена, в то время как на сцене может отображатся фактически только три примитива точка, линия и поверхность из треугольников. Взаимодействие с юзером, а именно просмотр и выбор обьектов мышкой идет через окно сцены.
VD>Ясно. А может вы просто про контроллер забыли?

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

K>> Если бы вид одевался бы непосредственно на модель,
VD>Что?

Если бы не было промежуточной развязки между основной моделью и сценой в виде 3d-модели.

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

Это совершенно корректный дизайн: создание промежуточного представления, когда сложность сочетаний растёт пропорционально произведению типов данных взаимодействующих слоёв. Ближайшая аналогия — p-код front-end компиляторов. Или же — представление триадами/тетрадами.

Здесь вполне логично использование связи с двумя "модельными" документами.

doc_3d --> some_object <-- doc_model

doc_3d использует часть интерфейса some_object для своей работы, doc_model, как я понимаю, полностью управляет some_object-ом. Что-то не пойму, в чём здесь проблема? И таки да, вполне возможно использовать унаследовать some_object от двух типов узлов списков — список элементов doc_model и список элементов doc_3d. Можно поспорить об эффективности такого решения, но однозначно заявлять о его "странности" неверно.

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

E>>Пользуясь случаем хочу задать вопрос c-smile о D (прошу прощения за оффтопик, по почте с c-smile у меня не получилось связаться ).

CS>Как так?

Да где-то месяц-полтора назад отправлял тебе пару сообщений и через RSDN и на e-mail в твоем профиле, но ответа не получил
Ну да спрашивал я у тебя там то же самое, что и сейчас. Так что ответ, в конце-концов, получил

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

VD>Хотелось бы услышать кто что думает по поводу необходимости подобных вещей в языках программирования.

МН побуждает к специфическому дизайну. Пользоваться таким подходом или нет — вопрос вкуса.

VD>Особо привествуются примеры в которых данные фичи дают резкое упрощение решаемой задачи.

Пример с интрузивными списками уже приводили. Ещё посмотри на потоки STL...

Хотя, конкретные примеры здесь всё равно ничего не дадут, потому что:

а) Без множественного наследования обойтись можно всегда;
б) Без наследования тоже обойтись можно всегда;
в) Без ООП также обойтись можно всегда;
г) Янус написан без множественного наследования.

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

Если хочешь, то это как раз случай NP-полной задачи: придётся перебрать все возможные варианты решений конкретной задачи и если на всём множестве решений фича YYYY даёт наиболее эффективные результаты, то лишь тогда можно будет считать, что её необходимость доказана. Но задачу надо брать достаточно увесистую — например, CRM какой-нибудь или чё поширше, одними только отдельно взятыми группами классов не обойдёшься.

Так что, получается, что ты побуждаешь собеседников к заведомо проигрышной позиции — что бы они не сказали в защиту МН, всё может быть опровергнуто слёту.

PS.: Собственно, сказанное выше уже прекрасно подтверждено ходом дискуссии.

PPS.: Есть только одна группа аргументов, которая перевешивает десятки мегабайт трафика таких дискуссий. Начинаются аргументы этой группы со слов: "Я хочу".

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

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

E>>>Пользуясь случаем хочу задать вопрос c-smile о D (прошу прощения за оффтопик, по почте с c-smile у меня не получилось связаться ).

CS>>Как так?

E>Да где-то месяц-полтора назад отправлял тебе пару сообщений и через RSDN и на e-mail в твоем профиле, но ответа не получил
E>Ну да спрашивал я у тебя там то же самое, что и сейчас. Так что ответ, в конце-концов, получил

Можешь сегодня/завтра послать письмо?

У меня этот адрес public, на него стоко всякого сыпется ... запросто могу выплеснуть чего-нить полезное.
Извиняюсь если что. Если не отвечаю — пошлите письмо еще раз please.

Кстати со спамом надо что-то делать. e-mail как система загибается, имхо.

Особенно тоскливо получать спам с mail.ru... За державу и культуру обидно право слово.

Кстати все public mail сервера России в глубоком бане на форуме http://www.terrainformatica.com/bb/index.php.
Пожалуйста используйте другие какие-нибудь адреса для регистрации.
Извиняюсь, но просто нет времени это г. разгребать.

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

ГВ>PPS.: Есть только одна группа аргументов, которая перевешивает десятки мегабайт трафика таких дискуссий. Начинаются аргументы этой группы со слов: "Я хочу".

Из этой же серии :

Если ваша жена начинает фразу со слов "ты всегда" или "ты никогда" — знайте, дальше последует неправда.
(принцип работает на 100% — проверено)

И вообще: Ubi nil vales, ibi nil velis...
(это не я сказал)

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

VD> ... Возможность свалить все в кучу немедленно приводит к сваливанию всего в кучу.

Эта максима надеюсь не из личного опыта...

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

VD>Хотелось бы услышать кто что думает по поводу необходимости подобных вещей в языках программирования.

VD>Особо привествуются примеры в которых данные фичи дают резкое упрощение решаемой задачи.
Вместо множественного наследования имхо подходит аналог Implements в Delphi когда за реализацию некоего интерфейса отвечает свойство класса которому передаются все вызовы.
Хэлперы (миксины) практически без особых проблем позволили приспособить дельфевую объектную модель к нетовской.
Так, что очевидно, что подобные вещи необходимы для упрощения реализации и подгонке под определенный стандарт и упрощение использования, классрв.

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

CS>Кстати все public mail сервера России в глубоком бане на форуме http://www.terrainformatica.com/bb/index.php.
Жаль, я Вам список багов (в том числе и в графическом виде) отправил...

CS>Пожалуйста используйте другие какие-нибудь адреса для регистрации.
Ладно, попробуем.

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

ГВ>И любой приводимый пример можно по такой схеме разнести в квантовую пыль, а значит,...

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

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

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

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

VD>Дело в том, что вчера мне потребовалось обосновать необходимость traits в Nemerle:
VD>http://nemerle.org/forum/viewtopic.php?t=244&sid=533a4646e8a58584c5dee21a456b355e
VD>и я задумался над аргументацией. Задумался, и понял, что ее в общем то у меня пока нет. Вот и решил получить помощь. Однако пока что никто ничего умного не сказал.
VD>Вот я и думаю, не является ли МН и его заменители эдакой показной фичей которая реально на фиг не упала, но так как в языке Х она есть, то и нам надо заиметь?

Так чем же история закончилась? И закончилась ли?

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

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

WH>>А как? Есть куча ВинФормсовских контролов. Каждый из которых должен реализовывать платформонезависимый интерфейс чтобы другие части системы могли работать независимо от того что именно ресует контролы. Скажем интерфейс IUIControl содержит порядка двух десятков элементов. А этот интерфейс должны реализовывать все видимые контролы.
WH>>Как тут обойтись без копипаста? Правильно миксины или множественное наследование реализации или макросы. Ни того ни другого ни третьего в C# нет.

VD>А в чем копипэст если ты реализуешь интерфейс в наследнике?

В том, что ты обогащаешь функциональностью уже имеющуюся иерархию, т.е. приходится обогащать каждый ее член. Причем, отсутствие MH действительно заставляет делать столько повторяющейся работы, что дешевле делать свою собственную иерархию, в которой инкапсулировать чужую. Т.е. свою иерархию неких MyControlBase. По крайней мере в моих экспериментах на эти же точно темы таким макаром получалось гораздо меньше "дурной" работы, несмотря на всякие тонкости с изменением структуры инкапсулируемой иерархии внешними воздействиями (т.е. возня с синхронизацией графов наших объектов и соотв инкапсулированных). Точно такие же задачи на С++ решались походя всего 1 раз, за счет МН и возможности указывать параметром шаблона тип, который будет в числе базовых.

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

Я бы сделал так, написал бы просто хелпер:

    static class ByteWriterHelper
    {
        static byte[] UInt32ToBytes(uint u)
        {
            byte[] bytes = new byte [4];

            // ...

            return bytes;
        }
    }

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

ЗЫ: а вот интерфейсы я бы не стал заменять абстрактными классами.

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

VD>Что касается разнесения в пух и прах, то разношу я явно безграмотный дизайн.

В том-то и дело, что это не так.

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

+1, и в самом деле, МН можно употребить откровенно криво. Но то же самое можно сказать и об ООП в общем — оно тоже порождает безграмотный ОО-дизайн. Так что, это не означает, что такой механизм в языке не нужен вообще. Примеров полезности МН продемонстрировано уже достаточно.

Засада в том, что как ни поверни, а с одной стороны, нет возможности однозначно доказать необходимость МН (Nemerle содержит, в общем, довольно мощный механизм макросов), а с другой — нет причин и отказываться от оного, если самый могучий контраргумент — потенциальное порождение "плохого" дизайна. Осциллограф тоже может ударить током, но это же не означает, что нужно от них отказываться?!

Посему, принятие решения о введении МН в Nemerle будет лежать в плоскости личных мотивов разработчиков языка. "Аргументация" сторонников МН здесь нужна только для создания видимости обоснованного решения. Её всегда можно будет вывернуть и так и эдак.

Хотя мне кажется, что как минимум один более или менее весомый аргумент можно выцарапать. А именно: как уже показали раньше, МН помогает решить некоторые проблемы использования внешних API. Так вот, кто может поручиться за то, что будущие Nemerle-API будут свободны от тех же проблем, для решения которых оказалось полезным МН?

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

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

K>Я бы сделал так, написал бы просто хелпер:
K>

K>    static class ByteWriterHelper
K>    {
K>        static byte[] UInt32ToBytes(uint u)
K>        {
K>            byte[] bytes = new byte [4];

K>            // ...

K>            return bytes;
K>        }
K>    }
K>

И дальше?

K>Хотя конечно, это нарушает принцип инкапсуляции. Но с другой стороны если посмотреть, то этот хелпер может быть нужен не только ByteWriter'у, так что с точки зрения дизайна мы ничего не нарушаем.

Мне нужен не хелпер сам по себе. Его действительн не обязательно определять внутри класса.

Мне нужен метод put(uint).

K>Ну а в случае когда действительно наш хелпер никому больше не нужен, то скорее всего такое решение становится костылем. Хотя это тоже спорно, зависит с какой стороны посмотреть

K>ЗЫ: а вот интерфейсы я бы не стал заменять абстрактными классами.

Альтернатива -- copy-past.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

VD>Document не имеет быть права контролом (Widget-ом) с точки зрения дизайна, в прочем как и фигурой (Shape) и исполнителем действий (Executor).

Паттерн "точка сборки" может быть кем угодно и чем угодно. (с) WoldemaR. Ссылка при цитировании обязательна.


VD>И того при нормальном дизайте этот класс будет вглядеть как-то так:
VD>

VD>// Объект создаваемый фабрикой
VD>[ClassFabric(X)]
VD>class Document : SchemaNode
VD>{
VD>  Properties Properties { get { Properties(); } }
VD>}
VD>

А почему это SchemaNode? У меня в отчёте и диаграммы и графики и схемы и буквы и картинки и линии и полигоны и стрелочки и всё это комбинируется в произвольном порядке.


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

VD>Не... получился бы хороший дизайн намного более подходящий для дольнейшего развития.

Мне кажется ты просто ещё не сталкивался с задачами построения сильно гибридизированных редакторов.
Полиморфное разделение объектов графического редактора, которое демонстрируется в каждом учебнике по ООП — тупиковый путь. индустрия ( -какое слово то!!!) от него уже давно отказалась.

Если есть желание "въехать в тему" могу предложить в качестве домашнего задания продумать архитектуру классов "универсального интерактивного графического редактора". Минимальный функционал описан в моём первом сообщении.
Желаю творческих узбеков.