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

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

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

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

Как вариант:
Вероятно, для решения подходит матаппарат редукции графов. Следовательно, декомпозиция системы первоначально долдна происходить не на объекты — а на функции (характеристики).
Узлы — функции, ребра — отношения. Отношения могут быть нескольких типов.
Сочетание Узел+Отношение рождают Решение (заготовку шаблона, частично конкретизированный шаблон).
Уточняющие итерации с поглощением "ребер-отношений" в конце концов приводят к программе.

Например, вот это : суперкомпиляция и частичные вычисления — это вроде бы как раз то, что я имел ввиду.

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

S>Например, вот это : суперкомпиляция и частичные вычисления — это вроде бы как раз то, что я имел ввиду.

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

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

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

Декомпозиция на "чёрные ящики" применяется не только в ООП. Можно сказать, что таким образом проектируется почти всё, что хоть немного сложнее палки-копалки.

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

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

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

Здравствуйте, x-code, Вы писали:
XC>Не понял примеры, но у меня есть похожая идея.
XC>Рассмотрим, например, организм. В нем есть разные подсистемы — нервная, кровеносная, пишеварительная и т.д. Все они выполняют разные функции, у них разная логика работы, но все они взаимопроникают друг в друга и используют друг друга в своей работе. Могут ли современные ООП-языки предложить удобный для программиста механизм реализации такого взаимопроникновения? Мне почему-то кажется, что нет. И, честно, с трудом представляю что бы это могло быть...
Более того, я, если честно, с трудом представляю, для чего это может понадобиться.

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

S>Как вариант:
S>Вероятно, для решения подходит матаппарат редукции графов. Следовательно, декомпозиция системы первоначально долдна происходить не на объекты — а на функции (характеристики).
S>Узлы — функции, ребра — отношения. Отношения могут быть нескольких типов.
S>Сочетание Узел+Отношение рождают Решение (заготовку шаблона, частично конкретизированный шаблон).
S>Уточняющие итерации с поглощением "ребер-отношений" в конце концов приводят к программе.

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

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

XC>>Рассмотрим, например, организм. В нем есть разные подсистемы — нервная, кровеносная, пишеварительная и т.д. Все они выполняют разные функции, у них разная логика работы, но все они взаимопроникают друг в друга и используют друг друга в своей работе. Могут ли современные ООП-языки предложить удобный для программиста механизм реализации такого взаимопроникновения? Мне почему-то кажется, что нет. И, честно, с трудом представляю что бы это могло быть...
S>Более того, я, если честно, с трудом представляю, для чего это может понадобиться.

Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.

Здравствуйте, Erop, Вы писали:
E>IMHO такой подход будет иметь те же недостатки, что и нейронные сети или воспитание детей -- невозможность исправлять ошибки...

Но все же смирились с тем что SQL сервер сам рулит планом выполнения запроса. Или, например, что автоматизация на Excel имеет строго ограниченные рамки как по интерфейсу, так и по набору решений (маршрутам решений).
Другой пример — результат представления HTML. Возможности здесь тоже дизайнера не бесконечны. Дизайнер уже не бог и король. Можно задать общие требования, однако окончательное "поведение" (например переносы строк, масштабирование табличек) будет определять engine браузера.
Однако, это все широко используется. Так же как и автомобили и утюги. Никто не делает дома руками нечто тратя человеко-годы нечто, только ради полного контроля над процессом.

Здравствуйте, Voblin, Вы писали:
V>Идея хорошая, но есть ненулевая вероятность получения генератора случайных программ. Избегать этого или стремиться к этому — хороший вопрос.

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

Но на вашем сайте однако есть же описание mixin технологии. Это довольно близко.

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

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

S>>Например, вот это : суперкомпиляция и частичные вычисления — это вроде бы как раз то, что я имел ввиду.

XC>Не понял примеры, но у меня есть похожая идея.

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

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

XC>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

S>Но все же смирились с тем что SQL сервер сам рулит планом выполнения запроса. Или, например, что автоматизация на Excel имеет строго ограниченные рамки как по интерфейсу, так и по набору решений (маршрутам решений).
S>Другой пример — результат представления HTML. Возможности здесь тоже дизайнера не бесконечны. Дизайнер уже не бог и король. Можно задать общие требования, однако окончательное "поведение" (например переносы строк, масштабирование табличек) будет определять engine браузера.
S>Однако, это все широко используется. Так же как и автомобили и утюги. Никто не делает дома руками нечто тратя человеко-годы нечто, только ради полного контроля над процессом.

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

А ты, насколько я понял, собираешься целенаправленно культивировать сложность и повышать степень связанности...

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

S>Я подумал что может кто то с этими параметрами знаком поглубже.
У Дейкстры были похожие идеии.
Их можно найти по ключевым словам weekest precondition...

Правда ничего более автоматического кроме правильного использования assert и парадигмы процедурного программирования эти идеи пока что не дали вроде...

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

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

XC>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

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

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

Какая разница следующая или предыдущая? Ты объясни как с поодержкой бороться?

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

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

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

S>>Но все же смирились с тем что SQL сервер сам рулит планом выполнения запроса. Или, например, что автоматизация на Excel имеет строго ограниченные рамки как по интерфейсу, так и по набору решений (маршрутам решений).
S>>Другой пример — результат представления HTML. Возможности здесь тоже дизайнера не бесконечны. Дизайнер уже не бог и король. Можно задать общие требования, однако окончательное "поведение" (например переносы строк, масштабирование табличек) будет определять engine браузера.
S>>Однако, это все широко используется. Так же как и автомобили и утюги. Никто не делает дома руками нечто тратя человеко-годы нечто, только ради полного контроля над процессом.

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

E>А ты, насколько я понял, собираешься целенаправленно культивировать сложность и повышать степень связанности...

Это верно в отношении HTML.

Но только не в отношении SQL или ДВС.

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

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

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

S>Но на вашем сайте однако есть же описание mixin технологии. Это довольно близко.

Спасибо что заглянули

В общем похоже, но есть отличия. У меня классы по-прежнему остаются "чёрными ящиками", но instance можно порождать сразу от нескольких классов. Взаимопроникновение, если это нужно, заранее чётко описывается. Если есть класс Foo и класс Bar, и мы предполагаем, что объекты, классифицируемые одновременно как Foo и как Bar имеют физический смысл и обладают какой-то дополнительной особенностью реализации, то эту особенность мы программим явно.

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

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

XC>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

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

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

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

XC>>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

Да, аспекты и моделирование характеристик.

Аспекты это весьма упрощено, а моделирование характеристик "позиционируется" как творческая методика.

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

S>Ну не скажите, "срок службы" человека гораздо больше срока службы автомобиля, например.
А пробег (если уж об автомобилях говорим) намного меньше...
S>Сколько стоит система серверов без поддержки и работает сама? Ну неделю ну две, а то иной раз приходишь в понедельник (всего то пару дней прошло) и начинаешь день с того, что то и это нужно перезапустить, перестартовать или перезагрузить, а то и посложнее ситуации.
Ресурс системы вообще-то часто можно любым спросктировать. У человека просто регенерация есть. Если ты к серверами регенерилку разработаешь, то и будет тебе счастье. Есть куча устройств, ПО которых работает бесконечно долго (много больше работы на отказ оборудования)

Во всяком случае мне лично неочевидно что предлагаемая метода это не то чтобы лучший способ повышения надёжности ПО, а вообще способ повышения надёжности...

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

XC>>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

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

S>Сколько стоит система серверов без поддержки и работает сама? Ну неделю ну две, а то иной раз приходишь в понедельник (всего то пару дней прошло) и начинаешь день с того, что то и это нужно перезапустить, перестартовать или перезагрузить, а то и посложнее ситуации.

Если устойчивый софт и ничего не трогать — может работать годами. У нас сервера баз данных так работают, хотя их постоянно дергают, не говоря уже о домен-контроллере, например, в который просто никто не лазиет.

Правда, какое это имеет отношение у теме — я не понимаю...

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

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

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

S>>Но на вашем сайте однако есть же описание mixin технологии. Это довольно близко.

V>Спасибо что заглянули

V>В общем похоже, но есть отличия. У меня классы по-прежнему остаются "чёрными ящиками", но instance можно порождать сразу от нескольких классов. Взаимопроникновение, если это нужно, заранее чётко описывается. Если есть класс Foo и класс Bar, и мы предполагаем, что объекты, классифицируемые одновременно как Foo и как Bar имеют физический смысл и обладают какой-то дополнительной особенностью реализации, то эту особенность мы программим явно.

Так это Ваша идея?? Я упоминание о ней в какой то книге видел.

Ну хорошо, класс "кружка" и клас "термос" будучи скрещеными рождают "кружку-термос". Тут идет дополнение методов или свойств. Этакий микс, сумма.

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

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

S>Но только не в отношении SQL или ДВС.
А что за "взаимопроникновение" есть в SQL?

S>"Взаимопроникновение" я думаю — это как раз то, что превращает промышленное проектирование ДВС, самолетов и кораблей в ОЧЕНЬ (и очень) дорогой процесс, нисмотря на то, что в концептуальном смысле (в кубиках) все понятно пятикласнику за пять минут.
А в чём оно выражается? В том, что на радиаторе кофе варят?

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

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

XC>>>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>>>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

F>А это все потому что, там есть электрическая, двигательная и топливная система и они "проникают друг в друга".
F>В общем, аналогии — плохой путь.

S>>Сколько стоит система серверов без поддержки и работает сама? Ну неделю ну две, а то иной раз приходишь в понедельник (всего то пару дней прошло) и начинаешь день с того, что то и это нужно перезапустить, перестартовать или перезагрузить, а то и посложнее ситуации.

F>Если устойчивый софт и ничего не трогать — может работать годами. У нас сервера баз данных так работают, хотя их постоянно дергают, не говоря уже о домен-контроллере, например, в который просто никто не лазиет.

F>Правда, какое это имеет отношение у теме — я не понимаю...

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

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

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

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

S>>Но только не в отношении SQL или ДВС.
E>А что за "взаимопроникновение" есть в SQL?

S>>"Взаимопроникновение" я думаю — это как раз то, что превращает промышленное проектирование ДВС, самолетов и кораблей в ОЧЕНЬ (и очень) дорогой процесс, нисмотря на то, что в концептуальном смысле (в кубиках) все понятно пятикласнику за пять минут.
E>А в чём оно выражается? В том, что на радиаторе кофе варят?

Ага, вот как раз типичный примерчик из учебника по ООП.

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

S>Так это Ваша идея?? Я упоминание о ней в какой то книге видел.

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

S>Ну хорошо, класс "кружка" и клас "термос" будучи скрещеными рождают "кружку-термос". Тут идет дополнение методов или свойств. Этакий микс, сумма.

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

Ага. Когда нужно будет разжечь печку, мы сможем поюзать бумажный самолётик вот таким вот неожиданным образом
Что характерно, нет никакого множественного наследования. Есть объект, который одновременно является и самолётиком, и бумажкой, хотя на этапе "проектирования системы" никто и не предполагал, что такое замечательное сочетание вообще возникнет и, соответственно, никто такой множественно-унаследовавший класс специально не создавал. И даже компилятор втихоря не создавал его имплементацию на основании своих шаблонов (порождая лишние мегабайты exe-шника). Просто по ходу "эксплуатации системы" так получилось, что самолётик возник и принёс свою маленькую пользу. Хоть и была его судьба печальна.

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

S>Однако, есть софт другого рода, изменчиовть которого — ну неотъемлемая часть эксплутационных характеристик. Учетные системы прежде всего. И вот здесь автоматическая -("на ходу") трансляция из изменяемых функциональных требований в целостный и надежный код — ну просто очень нужно.

Ну так тут как раз выгодно сло и абстракции вводить. Типа надёжный, продуманный и отлаженный framework и слой описывающий реальные бизнеспроцессы. Желательно тоде структурированный. Да ещё framework может проверять прикладной слой (..е слои) на непротиворечивость и совместимость...
А как тут взаимопроникновение должно помогать?

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

S>Ага, вот как раз типичный примерчик из учебника по ООП.
Таки можешь привести примеры позезного взаимопроникновения в технических или программных системах?

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

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

Хм, если вы не о переменных, а о методах — то CLOS вам в руки (вроде на Питоне можно динамически добавлять/изменять методы /* легче чем в Java */)

Если же именно о переменных, то... не могу себе представить как это использовать. Т.е. можно "засахарить" наследование с добавлением полей — и дописывать новые методы / изменять существующие... Т.е. новые поля без нового кода — нонсенс. Возьмите лисп и попробуйте — если что-то получится — сообщите

P.S. Только не надо вспоминать "отличительные особенности" лиспа В конце концов на лиспе может быть только "концепт". А там, если понравится — на чём угодно, хоть новый язык пишите

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

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

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

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

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

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

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

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

S>Однако, такой подход — весьма грубое приближение к реальности. Как правило, в любых функционирующих системах, особенно в живых наблюдается взаимовлияние объектов не только на уровне согласования входа-выхода, но и в смысле взаимной адаптации, взаимопроникновения, размазывания, в вырожденном варианте — по типу принципа голограммы (каждый кусочек способен отражать целое).
Это вопрос о том, какой критерий объектной декомпозиции использовать. Вот, например, возьмем стакан воды и растворим в нем ложку сахара и ложку соли. Получим композитный объект "раствор", для которого имеется такое вот "взаимопроникновение". Если мы имеем подобный объект и беремся его программно моделировать, то возникает вопрос, чем руководствоваться при различении в нем его составляющих, в каком контексте это различение производить? Если в качестве критерия взять чисто пространственное разделение, например, "верхняя половина стакана" и "нижняя половина стакана", то такая модель может оказаться неадекватна задаче. И при этом может возникнуть подобные размышления на тему "грубое приближение к реальности" и т.п. Если же в качестве критерия взять "химический" критерий, то различение будет четким и никаких расплывчатостей и неоднозначностей не возникнет, несмотря на то, что взаимопроникновение в пространственном аспекте будет.
Вобщем, думаю, что все зависит от критерия декомпозиции, который, в свою очередь, зависит от кондекста задачи.

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

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

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

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

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

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

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

E>>Какая разница следующая или предыдущая? Ты объясни как с поодержкой бороться?
XC>Честно говоря, не понял о чем вопрос

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

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

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

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

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

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

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

S>>Однако, такой подход — весьма грубое приближение к реальности. Как правило, в любых функционирующих системах, особенно в живых наблюдается взаимовлияние объектов не только на уровне согласования входа-выхода, но и в смысле взаимной адаптации, взаимопроникновения, размазывания, в вырожденном варианте — по типу принципа голограммы (каждый кусочек способен отражать целое).
A>Это вопрос о том, какой критерий объектной декомпозиции использовать. Вот, например, возьмем стакан воды и растворим в нем ложку сахара и ложку соли. Получим композитный объект "раствор", для которого имеется такое вот "взаимопроникновение".

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

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

Не те "слои" берете. Лучше возмем: стекло и форма.

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

S>Сведение проекций в одной точке — это и есть генерация объекта (объектов), а лучше сказать системы взаимодействующих функций. То есть все таки все сводится к чему то одному — целостному.

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

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

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

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

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

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

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

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

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

V>>... исключив напрочь идею наследования ..., а вместо этого дать возможность объявлять переменные, одновременно принадлежащие нескольким классам.

CU>Хм, если вы не о переменных, а о методах — то CLOS вам в руки (вроде на Питоне можно динамически добавлять/изменять методы /* легче чем в Java */)

Ну при чём же здесь мультиметоды? Я эту тему вообще не поднимал.

CU>Если же именно о переменных, то... не могу себе представить как это использовать. Т.е. можно "засахарить" наследование с добавлением полей — и дописывать новые методы / изменять существующие... Т.е. новые поля без нового кода — нонсенс. Возьмите лисп и попробуйте — если что-то получится — сообщите

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

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

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

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

Но проектируя в ООП, надо думать о взаимодействии объектов, а вовсе не о их иерархии.

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

E>>>Какая разница следующая или предыдущая? Ты объясни как с поодержкой бороться?
XC>>Честно говоря, не понял о чем вопрос

Ну вот написал ты автоматически програму с "взаимопроникновением слоёв". А она в каком-то частном случае не работает. Что делаем дальше?
Или, например, написал ты так банковское ПО, а там нарылася "задняя верь". И тебе надо её найти и извести и ещё остальные вычистить. Что делаем?

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


S>Сведение проекций в одной точке — это и есть генерация объекта (объектов), а лучше сказать системы взаимодействующих функций. То есть все таки все сводится к чему то одному — целостному.
Ну то есть реальные объекты -- это колелкции "проекций", или, каждая "проекция" -- это интерфейс, а объекты реализуют сразу много интерфейсов?

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

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

Ты про это?

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

S>Не те "слои" берете. Лучше возмем: стекло и форма.
И в чём проблема? Стеклянный стакан прекрасно наследует и свою форму и свой материал... Где тут вообще возникают сложности у ООП?

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

S>Не те "слои" берете. Лучше возмем: стекло и форма.

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

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

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

И кстати, я так и не понял — "взаимопроникновение" и "интерференция слоев", по твоему мнению — это плохо и с ней надо бороться, или хорошо и ее надо внедрять? А то из разных постов разное впечатление складывается.

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

XC>>В предлагаемой парадигме появляется N иерархий, независимых друг от друга. При этом один и тот же объект может принадлежать одновременно разным иерархиям. А сами иерархии становятся менее жесткими, благодаря чему объекты становятся более свободными.

S>Сведение проекций в одной точке — это и есть генерация объекта (объектов), а лучше сказать системы взаимодействующих функций. То есть все таки все сводится к чему то одному — целостному.

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

Просто пока не очень понятно (думаю, я здесь не одинок), о чём идёт речь и что же такое здесь должно взлететь

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

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

XC>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.

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

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

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

Хотя бы понять что именно пытаемся упростить...

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

V>Ну при чём же здесь мультиметоды? Я эту тему вообще не поднимал.

...как способ частичного "отлучения" от необходимости "жесткого наследования"

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

в случае с CLOS "прокрустово ложе иерархии классов" уже не такое "жесткое"... Но если вам и на нём "твёрдо" — добавьте/используйте ФП/ДП.

Я к тому, что ваш "поток сознания" без технической конкретики начинает напоминать... есть здесь один "адепт" "семантического программирования"

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

По описанию выглядит похоже на MPS, Intentional Programming и так далее, только сформулировано слишком неясно. Есть книга на эту тему — Чарнецки и другие, "Порождающее программирование"

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

V>>Ну при чём же здесь мультиметоды? Я эту тему вообще не поднимал.

CU>...как способ частичного "отлучения" от необходимости "жесткого наследования"

Sorry, мультиметоды, они на то и "мульти", что к одиночному объекту не применяются. Они ведь сделаны для описания логики взаимодействия объектов. А если объект один, но одновременно является и бумажкой, и самолётиком, куда тут приткнуть мультиметод? Что с чем взаимодействовать будет?

CU>в случае с CLOS "прокрустово ложе иерархии классов" уже не такое "жесткое"... Но если вам и на нём "твёрдо" — добавьте/используйте ФП/ДП.

Адепты ФП/ДП часто преподносят его как универсальное лекарство от всех болезней. Действительно штука весьма очаровательная. Но, к сожалению, применима не ко всем задачам. Бывает так, что "побочные эффекты" и "внутреннее состояние", от которых ФП избавилось — это очень нужные вещи (про монады мне не рассказывайте, я о них знаю). Когда исполнение программы — это вычисление (в самом классическом понимании, как получение "Output" из "Input" через выполнение "Program"), то ФП и карты в руки. Но если работа системы — это непрерывная деятельность, то ФП, конечно, на отдельных участках применимо, но в целом система — не "Ф".

CU>Я к тому, что ваш "поток сознания" без технической конкретики начинает напоминать... есть здесь один "адепт" "семантического программирования"

Упс... Что за зверь "семантическое программирование" — не ведаю

Господи, какая такая техническая конкретика? Меня зацепили на тему множественной классификации, работу по которой я и не планировал в ближайшую пятилетку переводить в практическую плоскость (если кому интересно, расскажу почему). Так что, друзья, не ворчите.

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

S>Однако, такой подход — весьма грубое приближение к реальности. Как правило, в любых функционирующих системах, особенно в живых наблюдается взаимовлияние объектов не только на уровне согласования входа-выхода, но и в смысле взаимной адаптации, взаимопроникновения, размазывания, в вырожденном варианте — по типу принципа голограммы (каждый кусочек способен отражать целое).

В хреново написанных системах такое наблюдается. Чем хреновее написана, тем больше наблюдается.

S>Хороший пример — такая динамическая система как речь.

Зачем равнять природные вещи с искусственными? у природы ни сроков, ни клиентов, ни приемки работ нет — времени ну очень дофига, что выросло, то выросло.

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

Бесполезное занятие. Чтобы такое работало, надо сначала научиться требования формулировать в автоматизированном виде, понятном автомату. Это как правило не умеют.

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

Multi-stage Programming
A Taxonomy of meta-programming systems

V>(если кому интересно, расскажу почему).

Давай, интересно Тем более что и форум подходящий

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

V>>Меня зацепили на тему множественной классификации, работу по которой я и не планировал в ближайшую пятилетку переводить в практическую плоскость (если кому интересно, расскажу почему).

L>Давай, интересно Тем более что и форум подходящий

Всё просто. Дело в том, что практический выход этой штуки (см. здесь) может быть только один — создание системы программирования (язык + среды разработки для разных платформ + библиотеки + сообщество "пользователей"). А это либо должно стать делом всей жизни, либо за это вообще не стоит браться. А мне посвятить свою жизнь этому совсем не хочется. У меня есть другая "хрустальная мечта".

Что касается идеи множественной классификации, то это конечно восхитительная вещь, но мэйнстрим всей своей колоссальной массой ломанулся, не подумав, по другому пути. Ну представьте себе, что будет если выяснится, что в очередной версии MS VC++ лишится механизма наследования, а вместо этого этого появится какая-то странная штука, про которую в Буче не написано? Это ж мировой катаклизьм!

Так что если у кого-то есть желание подхватить знамя, то you are wellcome! А что, на этой штуке уж по крайней мере диссер-то можно защитить. Я ж готов в свободное от остальных дел время выступить в роли полувиртуального отца-основателя. В качестве бонуса даже могу ещё каких-нибудь идей накидать

Здравствуйте, palm mute, Вы писали:
PM>Multi-stage Programming
PM>A Taxonomy of meta-programming systems

Спасибо. Читаю...

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

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

PM>Multi-stage Programming
PM>A Taxonomy of meta-programming systems


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

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

1) есть набор примитивов кода таких как структуры и функции.
Это то — из чего будет состоять код конечной программы. Это с одного полюса.

2) На другом полюсе существуют слои абстракции- множество объектов и допустимых отношений между объектами.

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

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

3) Слои абстракций транслируются с верхнего уровня на нижий.

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

НИ ОДИН ИЗ ОБЪЕКТОВ, кроме объектов на самом нижнем уровне НЕПОСРЕДСТВЕННО НЕ связан с примитивами кода.

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

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

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

Затем уничтожаются формальные противоречия и производится формальная редукция.

Далее процесс повторяется.

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

V>Sorry, мультиметоды, они на то и "мульти", что к одиночному объекту не применяются. Они ведь сделаны для описания логики взаимодействия объектов. А если объект один, но одновременно является и бумажкой, и самолётиком, куда тут приткнуть мультиметод? Что с чем взаимодействовать будет?

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

V>Адепты ФП/ДП часто преподносят его как универсальное лекарство от всех болезней.

Я же писал _ДОБАВИТЬ_, а не _использовать только его_.

P.S. И плюс к этому превосходный мета-аппарат...

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

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

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

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

<сорри, отквотить надо было больше, но тут такие злые модеры... >

Мне напоминает "макры, которые генерят макры, которые генерят макры... которые локально переопределяют глобальные макры, которые..." — короче "гипер-динамическая супер-генерация" кода . Или я так и не понял?

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

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

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

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

V>>>Меня зацепили на тему множественной классификации, работу по которой я и не планировал в ближайшую пятилетку переводить в практическую плоскость (если кому интересно, расскажу почему).

L>>Давай, интересно Тем более что и форум подходящий

Ты знаешь, почитал твою статью и не увидел (или не заметил?) ни слова о языках с динамической типизацией. А они как раз ИМХО отлично подходят для того класса задач на который ты нацелился.

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

L>Ты знаешь, почитал твою статью и не увидел (или не заметил?) ни слова о языках с динамической типизацией. А они как раз ИМХО отлично подходят для того класса задач на который ты нацелился.

Не то чтобы отлично, но подходят. Говорю как человек, который в основном такие языки и юзает

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

Хлеб должен быть белым. А икра... чёрт с ней, пусть будет чёрной.

V>заранее определённый и описанный набор типов).
Почему заранее определённый? Это для статических языков он заранее определённый, для динамических — всё вычисляется в рантайме. По крайней мере, никаких преград перед тем чтобы изменять типы в рантайме я не вижу.

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

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