Voblin,

V>Сами миксины (как и само слово "mixin") — не моя находка. Моя идея состояла в том, что было бы неплохо немножко подрихтовать идею ООП, исключив напрочь идею наследования (при этом автоматически уходит дилемма "одиночное vs множественное"), а вместо этого дать возможность объявлять переменные, одновременно принадлежащие нескольким классам.

Всё уже украдено до нас.

trait Aircraft { def fly() = {...} }
trait Lighter { def fire() = {...} }

class MyPervertWayToSetTheFire extends Aircraft with Lighter {
    // здесь у нас есть и fly, и fire
}

тип MyPervertWayToSetTheFire может быть скажем вложенным, или анонимным, если соответствующий объект вообще возникает в одном месте.

Вообще, если rtfm "Scala programming language mixin composition", то можно найти много очень интересного. А если "Scala programming language type system", то глядишь, самый бурный полёт фантазии вдруг окажется совсем не бурным, и вовсе даже не полётом

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

LCR>Всё уже украдено до нас.

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

LCR>

trait Aircraft { def fly() = {...} }
trait Lighter { def fire() = {...} }

class MyPervertWayToSetTheFire extends Aircraft with Lighter {
    // здесь у нас есть и fly, и fire
}

Чем-то мне эта конструкция не очень нравится. Почему, например, именно так, а не "... extends Lighter with Aircraft"? И что будет, если и Lighter, и Aircraft имеют свойство Volume, которое в первом случае означает объём сжиженного газа в куб.см., а во втором — объём грузового отсека в кубометрах? Как-то это всё рыхловато и небезопасно. Не аккуратно, доктор.

У меня нет никакого желания пинать Скалу. Удачи всем, кто её юзает.

LCR>Вообще, если rtfm "Scala programming language mixin composition", то можно найти много очень интересного. А если "Scala programming language type system", то глядишь, самый бурный полёт фантазии вдруг окажется совсем не бурным, и вовсе даже не полётом
За наводку спасибо. Действительно интересно

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

CU>Ну может хоть краем глаза гляните на дженерики в CLOS, [пере]определение "наследования" — в кавычках не случайно, а намеренно, ибо реализация выбора (какой метод /* НЕПРАВИЛЬНО — какую _дженерик-функцию_ */ выполнять) делает "наследование" лишь одним из возможных (и по умолчанию) вариантом поведения /* который опять-же может меняться по ходу выполнения программы в зависимости от каких угодно факторов */, на MOP. Можно ещё на AspectL посмотреть — для примера как он всем этим пользуется, но для этого лисп/CLOS уже надо знать/понимать

Краем глаза глянул на CLOS. Мозг свернулся в трубочку и на внешние раздражители не отзывается
Теперь у меня такой вопрос: привыкание к этому наркотику наступает с первой дозы или у меня ещё есть шанс?

CU>P.P.S. Я к тому что попытаться изобразить концепт вашей идеи было бы проще на лиспе (каюсь "проще" — мне Но я своим закостенелым сознанием так и не могу "осознать" чего же вы хотите

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

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

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

S>>Почитал. Ладно.
S>>Предложу некую реализацию того о чем я говорю.

S>>Реализация состоит в том, что

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

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

Первый же очень простой пример: нужно написать программку на C#, в которой происходит работа с данными: они сохраняются, добавляются и удаляются.
Допустим речь идет о единственной основной табличке и паре справочников.
Кроме того, нужна проверка на логическую целостность данных во время ввода и управление правами.

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

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

Далее, все это создано, нарисованы классы все работает.
Теперь мы добавили поля.
Тыдыщь.
Если в отношении формы наследование и поможет, то для "объекта" БД — отнюдь. Там метод передающий параметры просто придется переписать.

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

Voblin,

LCR>>Всё уже украдено до нас.
V>Отнюдь. Поле просто необъятное. Просто вся толпа, как правило, пасётся рядом с динозаврами. С точки зрения личного благополучия это действительно очень выгодно. И, главное, надёжно. Но никто ж не мешает тёмной ночкой сходить в далёкий дикий лес и почесать свой мозг об ещё никем не помеченное дерево
Абсолютно согласен! Надо было сказать чуть по-другому: "это было украдено до вас"

V>Чем-то мне эта конструкция не очень нравится. Почему, например, именно так, а не "... extends Lighter with Aircraft"?
В данном случае (без volume) получится эквивалентный класс.

V> И что будет, если и Lighter, и Aircraft имеют свойство Volume, которое в первом случае означает объём сжиженного газа в куб.см., а во втором — объём грузового отсека в кубометрах? Как-то это всё рыхловато и небезопасно. Не аккуратно, доктор.
Всё аккуратно и чётко, см. "Scala, class linearization", "Scala, class members".

Defnition 5.1.5 A concrete member of a class C is any concrete defnition M in someclass C_i \in L(C), except if there is a preceding class C_j \in L(C) where j < i which directly defines a concrete member M' matching M.

L(C) — это линеаризация класса C, определение линеаризации смотрим в разделе 5.1.2, которое означает (интуитивно), что любой, даже самый дикий микс из классов, абстрактных классов и трейтов можно вытянуть в цепочку, и те классы (абс. классы/трейты), которые в этой цепочке левее, давят тех, которые правее.

Построение самой цепочки муторно и сейчас неважно, важно что это обобщение наследования. В самом простом случае, когда класс C производный от B, цепочка будет {C, B}.

В нашем случае, если и Lighter, и Aircraft имеют метод Volume(), то C extends Lighter with Aircraft будет содержать Volume() из Aircraft, ибо линеаризация класса C есть {C, Aircraft, Ligher} (правда в реальном коде надо ещё явно сказать override, в Scala переопределение методов явное — научены горьким опытом-с).

V>У меня нет никакого желания пинать Скалу. Удачи всем, кто её юзает.
Спасибо тебе, уважаемый Voblin, на добром слове
Когда тебя посетит следующее озарение, и ты придумаешь что-нибудь типа

Value class types, Nonnullable types, Monad types, Trait types, Singleton object types (procedural modules, utility classes, etc.), Compound types, Functional types, Case classes, Path-dependent types, Anonymous types, Self types, Type aliases, Generic types, Covariant generic types, Contravariant generic types, Bounded generic types, Abstract types, Existential types, Implicit types, Augmented types, View bounded types, Structural types, Higher-kinded types...

ты сначала глянь ScalaReference, авось там это уже есть

Voblin,

Небольшое уточнение для моего предыдущего поста

Автор: Lazy Cjow Rhrr
Дата: 13.05.08

. Это связано с правилами переопределения членов классов в Scala.

Упростим твой пример про зажигалки и самолёты.

trait A { def x = 666; def y = "A"}
trait B { def x = 777; def z = "B"}
class C extends A with B {}

Этот код приведёт к ошибке, потому что, с одной стороны, переопределять x нужно явно, а с другой — чтобы что-то переопределять, оно должно существовать.

Корректно делать либо так:

trait V { def x: Int }
trait A extends V { override def x = 666; def y = "A"}
trait B extends V { override def x = 777; def z = "B"}
class C extends A with B {}

либо так:

trait A { def x = 666; def y = "A"}
trait B { def x = 777; def z = "B"}
class C extends A with B { override def x = super[A].x }

либо так:

trait A { def x = 666; def y = "A"}
trait B { def x = 777; def z = "B"}
class C extends A with B { override def x = super[B].x }

То есть фраза "C extends Lighter with Aircraft будет содержать Volume() из Aircraft" была не совсем корректной. На самом деле это верно для первого случая (где трэйт V), а для других случаев — как хочешь так и будет.

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

LCR>Когда тебя посетит следующее озарение, и ты придумаешь что-нибудь типа
LCR>

Value class types, Nonnullable types, Monad types, Trait types, Singleton object types (procedural modules, utility classes, etc.), Compound types, Functional types, Case classes, Path-dependent types, Anonymous types, Self types, Type aliases, Generic types, Covariant generic types, Contravariant generic types, Bounded generic types, Abstract types, Existential types, Implicit types, Augmented types, View bounded types, Structural types, Higher-kinded types...

LCR>ты сначала глянь ScalaReference, авось там это уже есть

Как всё запущено!

Посмотрел. Понравилось. Даже захотелось поюзать на досуге

Если всё так хорошо, то где же подвох? Баги? Тормознутость компилятора? Монструозность получаемого бинарника? Принципиальная ограниченность рамками "песочницы"? Или просто [пока] небольшая распространённость?

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

V>Краем глаза глянул на CLOS. Мозг свернулся в трубочку и на внешние раздражители не отзывается
V>Теперь у меня такой вопрос: привыкание к этому наркотику наступает с первой дозы или у меня ещё есть шанс?

Ну, жить будешь, но постоянное ощущение "чего-то не хватает" тебя уже не покинет

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

В одном ты прав — в "этом огороде" концепт как таковой и останется, но после "обкатки" его можно будет "зарелизить" в других языках/технологиях/средах

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

V>Посмотрел. Понравилось. Даже захотелось поюзать на досуге

V>Если всё так хорошо, то где же подвох?

А он должен быть? Сейчас придут "любители Н" и скажут — макр нет Хотя это и я могу сказать

V>Баги?

А у кого их нет?

V>Тормознутость компилятора?

Это принципиально?

V>Монструозность получаемого бинарника?

Не без этого. Возможно переписав необходимый вам функционал на чистой джаве вы и получили бы выигрыш по размеру и скорости, но... Оно вам надо?

V>Принципиальная ограниченность рамками "песочницы"?

На сайите всё написано. Интероп с джавой "полный". В обратную сторону конечно несколько ограничен

V>Или просто [пока] небольшая распространённость?

Я думаю побольше чем у других "небазовых" языков под JVM.

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

V>>Если всё так хорошо, то где же подвох?
CU>А он должен быть? Сейчас придут "любители Н" и скажут — макр нет Хотя это и я могу сказать
Ну, макры — это такая палка о двух концах, что лучше уж без них. Самый надёжный способ запутать код — это написать побольше макросов. Иногда работает лучше, чем GOTO

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

V>Ну, макры — это такая палка о двух концах, что лучше уж без них. Самый надёжный способ запутать код — это написать побольше макросов. Иногда работает лучше, чем GOTO
Это ты еще Continuation не видел реализуются они при помощи спагетти стека

А вобще в правильных руках макры код распутывают.
Причем иногда очень не хило так распутывают.

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

V>Ну, макры — это такая палка о двух концах, что лучше уж без них. Самый надёжный способ запутать код — это написать побольше макросов. Иногда работает лучше, чем GOTO

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