Здравствуйте, Voblin, Вы писали:
V>Может быть, кому-нибудь будет интересно. V>http://voblin.nm.ru/objects_classes.dhtml V>Сразу вопрос: стоит ли это опубликовать в RSDN?
ну, написано неплохо, даже хорошо.
Мне понравилось, только по-моему, необходимо перед определением Объекта и экземпляра,дать определение класса.т.е. ты говоришь, что
Объект, экземпляр – информационная сущность, которой можно оперировать как единым целым.
что это за информационная сущность, мне кажеться. что
Класс является информационной сущностью,
а уже объектами класса можно оперировать как единым целым.
после определения класса стоит сказать, что можно создавать множество элементов, обладающих свойствами этого класса, и как раз эти элементы и являются Объектами.
т.е. можно привести жизненный пример:
у нас есть понятие сапожник,
если мы говорим, что Петя- сапожник, то все понимают, что Петя:
1)Мужского пола
2)Много материться
Ну вообще это только мое мнение.
...Почему разум становится более ленивым по мере развития технологий? Он привыкает к ним и не заботится о разработке новых...
Re[2]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, MadCoders, Вы писали:
MC>Мне понравилось, только по-моему, необходимо перед определением Объекта и экземпляра,дать определение класса.т.е. ты говоришь, что MC> Объект, экземпляр – информационная сущность, которой можно оперировать как единым целым.
MC>что это за информационная сущность, мне кажеться. что MC>Класс является информационной сущностью, MC>а уже объектами класса можно оперировать как единым целым.
Изюминка в том и состоит, что отталкиваюсь я не от определения класса. Понятие класса появляется только в разделе "классификация". Если отталкиваться от понятия класса, то получится обычное, известное всем с пелёнок ООП, и ничего интересного не произойдёт.
Re: Статья про развитие идей ООП. Жду комментариев.
Есть сильное подозрение, что в каких-нибудь исследовательских языках
все это давно рассмотрено и реализовано.
IMHO, в одном из диалектов LISP-а что-то подобное есть.
А в промышленные языки такое все-равно не пойдет — слишком сложно и для реализации,
и для использования.
Элементарные-то вещи реализовать в основных языках (С++, Java, C#, VB) не могут,
а тут такая революция.
V>Сразу вопрос: стоит ли это опубликовать в RSDN?
Конечно!
Re[2]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Аноним, Вы писали:
А>Есть сильное подозрение, что в каких-нибудь исследовательских языках А>все это давно рассмотрено и реализовано.
Не удивлюсь.
А>IMHO, в одном из диалектов LISP-а что-то подобное есть.
Где-то когда-то всплывал CLOS.
По-моему, предлагаемое решение больше касается "обычных" языков программирования нежели языков логического программирования тип LISP и Prolog.
А>А в промышленные языки такое все-равно не пойдет — слишком сложно и для реализации, А>и для использования.
Капля камень точит.
Реализация, конечно, сложновата, но, по-моему, овчинка выделки сторит.
Не добежим, так согреемся
А>Элементарные-то вещи реализовать в основных языках (С++, Java, C#, VB) не могут, А>а тут такая революция.
А что делать?
V>Сразу вопрос: стоит ли это опубликовать в RSDN? А>Конечно!
Попробую.
Re[3]: Статья про развитие идей ООП. Жду комментариев.
От:
Аноним
Дата:
08.05.03 11:15
Оценка:
Здравствуйте, Voblin, Вы писали:
V>Где-то когда-то всплывал CLOS.
Так он и сейчас есть (и компиляторы, и IDE, и библиотеки), а что толку? Кто на нем пишет?
V>По-моему, предлагаемое решение больше касается "обычных" языков программирования нежели языков логического программирования тип LISP и Prolog.
Что там такого в LISP-е логического?
Вполне "нормальньй" язык (относительно конечно), только возможностей много.
Вот никто и не пользуется — боятся, видимо.
V>Не добежим, так согреемся
Разве что.
Будет ли пользоваться успехом язык, в котором есть только одна фича (по сравнения, скажем с C#),
но зато полно недостатков — нет такой мощной поддержки, кучи библиотек (стандартных и сторонних),
серьезного компилятора и средства разработки, поддержки средств моделирования (например от Rational)
и т.п. и т.д. Можно продолжать бесконечно...
Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам
(видимо программист пошел совсем недалекий).
Наглядный пример Java и VB — полные ничтожества в языковом плане, никаких понят... тьфу возможностей,
однако ведь лидеры промышленной разработки.
Где все разработки 70-х, 80-х годов — вычисляемые типы, контракты, пред- и постусловия, частично параметризованные функции,
лямбды, замыкания и т.д.?
Даже примитивный С++ с его жалкими темплейтами оказался слишком сложен — и вот вам С#!
Если же кого-то интересуют навороченные языковые возможности, то есть тот же CLOS, Smalltalk, SML, Haskell
(последний вроде как уже есть под .NET — H#).
Re[4]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Аноним, Вы писали:
А>Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам А>(видимо программист пошел совсем недалекий).
А по моему все логично. Индустрия развивается, задачи формализуются, приоритеты расставляются... Вспомните операционные системы 70-х, 80-х годов... убожество, с которым пытались справится с помощью навороченных языков. А проблема-то была в другом! В ублюдочных runtime и платформе ...
А>Наглядный пример Java и VB — полные ничтожества в языковом плане, никаких понят... тьфу возможностей, А>однако ведь лидеры промышленной разработки.
Дык, они могут себе позволить быть ублюдочными... т.к. базируются на мощных платформах. Можно пойти дальше — я встречал проекты (как правило учет), в которых были реализованны системы метаданных (считай расширенная платформа). На абсолютно ублюдочном xml писались системы учета огромных складов, отделов кадров и т.д.
А>Где все разработки 70-х, 80-х годов — вычисляемые типы, контракты, пред- и постусловия, частично параметризованные функции, А>лямбды, замыкания и т.д.?
И зачем это все? Жалкие попытки проэмулировать возможности COM...
А>Если же кого-то интересуют навороченные языковые возможности, то есть тот же CLOS, Smalltalk, SML, Haskell А>(последний вроде как уже есть под .NET — H#).
Какие концептуальные задачи вы будете решать этими инструментами?
Игорь
Re[4]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Аноним, Вы писали:
А>Будет ли пользоваться успехом язык, в котором есть только одна фича (по сравнения, скажем с C#), А>но зато полно недостатков — нет такой мощной поддержки, кучи библиотек (стандартных и сторонних), А>серьезного компилятора и средства разработки, поддержки средств моделирования (например от Rational) А>и т.п. и т.д. Можно продолжать бесконечно...
Стоп-стоп-стоп. Речь идёт не только и не столько о том, что неплохо было бы выдумать новый язык программирования и среду разработки к нему. Конечно, хочется слепить что-то по-быстрому для опытов, но создавать какой-то сверхмощный коробочный продукт и двигать его на роль индустриального стандарта... Об этом речь пока что не идёт.
Вопрос в том, имеет ли право на жизнь подход, основанный не на однозначной, а на множественной классификации, когда:
А>Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам А>(видимо программист пошел совсем недалекий).
Предложенная парадигма не проще и не сложнее обычного ООП. Она просто другая.
Re[5]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, joker6413, Вы писали:
А>Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам А>(видимо программист пошел совсем недалекий).
J>А по моему все логично. Индустрия развивается, задачи формализуются, приоритеты расставляются... Вспомните операционные системы 70-х, 80-х годов... убожество, с которым пытались справится с помощью навороченных языков. А проблема-то была в другом! В ублюдочных runtime и платформе ...
Давайте не будем разводить спор о том, какое средство разработки лучше. Это бессмысленно.
Re[6]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Voblin, Вы писали:
V>Стоп-стоп-стоп. Речь идёт не только и не столько о том, что неплохо было бы выдумать новый язык программирования и среду разработки к нему. Конечно, хочется слепить что-то по-быстрому для опытов, но создавать какой-то сверхмощный коробочный продукт и двигать его на роль индустриального стандарта... Об этом речь пока что не идёт.
Да я и не собирался затевать гнилой базар по поводу — "да зачем все это надо я ж на turbo pascal и так фсе напишу"...
V>Вопрос в том, имеет ли право на жизнь подход, основанный не на однозначной, а на множественной классификации, когда:
Вот только я так и не понял сути — судя по картинке мы отказываемся от одиночного наследования в пользу множественного, плодим singletonы и вуаля — все по новому? В чем новизна?
Здравствуйте, joker6413, Вы писали:
J>Вот только я так и не понял сути — судя по картинке мы отказываемся от одиночного наследования в пользу множественного, плодим singletonы и вуаля — все по новому? В чем новизна?
Если под этим понятием скрывается паттерн проектирования "Одиночка".
Новизна — в сознательном отказе от концепции наследования и в том, что при этом мы получаем даже бОльшую возможность обобщения, бОльшую гибкость в плане полиморфизма, начинаем говорить с реляционными БД на одном языке, значительно улучшается расширяемость систем, отпадает необходимость всяких уродств типа абстрактных классов и темплэйтов и, в конце концов, можем делать объектную модель похожей на реальное положение вещей
Просьба: не надо меня размазывать по стенке за нелюбовь к темплэйтам. Я знаю что это такое и умею применять, но каждый раз после того, как такое случается, с чувством омерзения иду мыть руки. А потом иду смотреть, не добавила ли моя невинная шалось к размеру exeшника лишних килобайт 100
Re: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Voblin, Вы писали:
V>Может быть, кому-нибудь будет интересно. V>http://voblin.nm.ru/objects_classes.dhtml V>Сразу вопрос: стоит ли это опубликовать в RSDN?
Недостаток данного подхода именно в черзвычайной гибкости. Очевидно, это приведёт в строгому и сложному механизму органичения/разрешения/последовательности наследования.
Достаточно хорошим подходом является так называемый Class mixing. Объявляются так называемые классы-примеси, которые соответствуют строго определённым контрактам. И результирующие классы строятся с использованием классов-примесей, дающих необходимый вкус (flavour).
Типичная mixing library, на мой взгляд, это ATL/WTL.
Здравствуйте, Akzhan, Вы писали:
A>Недостаток данного подхода именно в черзвычайной гибкости. Очевидно, это приведёт в строгому и сложному механизму органичения/разрешения/последовательности наследования.
Конечно, если не предпринимать каких-то очень специальных действий, ничто не помешает создавать объекты самых бессмысленных сочетаний. Ну да, можно создать помесь кошки и собаки. Ну да, по команде "Голос" оно гавкнет и мяукнет...
Думаю, в сочетании со строгой типизацией катастроф не будет. Ведь в любом же языке программирования есть возможность написать что-то вроде "а = 1/0".
A>Достаточно хорошим подходом является так называемый Class mixing. Объявляются так называемые классы-примеси, которые соответствуют строго определённым контрактам. И результирующие классы строятся с использованием классов-примесей, дающих необходимый вкус (flavour).
A>Типичная mixing library, на мой взгляд, это ATL/WTL.
Где можно прочитать про Class mixing?
Yandex и Google вываливают кучу мусора
Re[3]: Статья про развитие идей ООП. Жду комментариев.
Я тут на досуге средствами C# и с системным подходом пытался моделировать структуры простейших геологических систем. Теперь есть ощущение, что средствами ООП сделать это (по крайней мере логично) нереально.
Ваши идеи выглядят очень привлекательно. Очень заинтересован в их развитии.
Конкретных комментариев, к сожалению, пока дать не могу, т.к. нет еще оформившихся мысел.
Удачи
... << RSDN@Home 1.0 beta 6a >>
Re[3]: Статья про развитие идей ООП. Жду комментариев.
Насколько я понял из Ваших ссылок, механизм примесей по своей сути является вариантом множественного наследования и применяется там, где "лобовое" множественное наследование либо не поддерживается языком либо его не хочется применять.
То, что предлагаю я, вообще обходися без наследования. То есть в самом прямом смысле — мы можем обойтись безо всякой иерархии классов. Составление "коктейля", содержащего все необходимые "примеси" происходит по мере необходимости.
В простейшем случае объект может являться смесью, составленной из любого произвольного сочетания объявленных в программе классов.
В более сложном случае (для этого нужно приложить соответствующее усилие при программировании) мы можем наложить условие, что, например, объект может быть либо Male, либо Female, а и тем и другим одновременно быть не может. Да простят меня представители сексуальных меньшинств
Насколько я понял, ни в одном из существующих языков программирования нет возможности породить экземпляр более чем двух классов. Например, вот так:
' VBDim MyObj As (Person, Male)
// C++
(Person, Male) *MyObj;
То, что описано в статье, мало того что позволяет так делать (подумаешь, ещё одна спорная "фича", к тому же потенциально весьма опасная), но и основывает на этом механизме технологию проведения безусловно самой главной фазы OOD — описание задачи в виде системы классов.
Re[5]: Mixins - вариант множественного наследования?
В варианте mixin architecture это выглядит так же, но более строго. Поэтому все возможные ошибки ловятся ещё на этапе компиляции. Единственное разлчие — невозможность динамического изменения типа — мутации. Другое дело, что я считаю мутации объектов вредной техникой с точки зрения поддержки кода. Но если нужны мутации, то надо использовать паттерн объект-стратегия.
class CMyObject :
public CCompoundObject, CPersonT<CMyObject>, CMaleT<CMyObject>
{
};
CMyObject myObj;
Здравствуйте, Voblin, Вы писали:
V>То, что предлагаю я, вообще обходися без наследования. То есть в самом прямом смысле — мы можем обойтись безо всякой иерархии классов. Составление "коктейля", содержащего все необходимые "примеси" происходит по мере необходимости.
V>В простейшем случае объект может являться смесью, составленной из любого произвольного сочетания объявленных в программе классов.
V>В более сложном случае (для этого нужно приложить соответствующее усилие при программировании) мы можем наложить условие, что, например, объект может быть либо Male, либо Female, а и тем и другим одновременно быть не может. Да простят меня представители сексуальных меньшинств
V>Насколько я понял, ни в одном из существующих языков программирования нет возможности породить экземпляр более чем двух классов. Например, вот так:
V>
V> ' VB
V> Dim MyObj As (Person, Male)
V>
V>
V> // C++
V> (Person, Male) *MyObj;
V>
Почему же нет возможности? Немного смекалки и все будет