Здравствуйте, Сергей Губанов, Вы писали:

СГ>ООП и Модульность — ортогональные понятия. Попытка соединить ООП и Модульность в одном флаконе, с неизбежностью приводят к появлению, того же самого COM или его аналогов.

А это как... плохо или хорошо?

СГ> ООП может существовать само по себе, Модульность — тоже может существовать сама по себе, но чтобы они были вместе и одновременно — нужен COM или его аналоги, которые называются КОМПОНЕНТАМИ, а программирование в стиле ООП+Модульность называется Компонентно Ориентированным программированием — КОП. В тоже самое время в связке ООП+Модульность, само ООП не может остаться прежним, оно нуждается в некоторой модификации, а именно ОГРАНИЧЕНИИ. Вспомни что такое COM интерфейсы в терминологии С++ — это классы без членов-данных, а все члены-функции ВИРТУАЛЬНЫ. Другими словами, ограничение наложенное на ООП состоит в том, что МЕЖМОДУЛЬНОЕ наследование возможно только от АБСТРАКТНЫХ классов.

Нда. Эдакий взгляд на жинь из дупла. То что заметил — существует. Остальное — миф.

Представь себе, что компонентность не равно КОМ. Есть и другие реализации. И они не имеют ограничений присущих КОМ-у.

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

В Яве и дотнете все доведено до блеска и практически все классы хранятся в отдельных сборках. При этом никаких проблем с наследованием от класса находящегося в другой сборке (длл-и) нет.

СГ> С COM — все так в точности и обстоит, из DLL-лек мы можем импортировать именно только ИНТЕРФЕЙСЫ, а не сами классы — это ОГРАНИЧЕНИЕ НАЛОЖЕННОЕ НА ООП при его слиянии с МОДУЛЬНОСТЬЮ.

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

СГ>Если бы из DLL можно было бы импортировать не интерфейсы, а сами классы и от них наследоваться, то таким образом построенные системы не были бы МОДУЛЬНЫМИ — ведь в этом случае динамическая загрузка одного модуля (с определением какого-то класса) в память всегда должна была бы сопровождаться динамической загрузкой в память всех-всех-всех остальных модулей в которых находятся классы-предки того класса (загрузка в память класса обозначает загрузку в память всех-всех-всех классов предков).

Это твоя теория. На самом деле модули могут грузиться по мере использования. Если, например, в программе есть класс Б и С и С унаследован от класса А расположенного в другом модуле. То до обращения к методам класса С модуль в котором размещен класс А не обязан загружаться в память. Так что класс Б можно использовать даже если сборки с классом А вообще нет на диске.

СГ>А в модульных системах такого безобразия быть не должно

Опять же не верное предположение. Нет никакого ограничения на то когда подгружать зависимые сборки (в дотнете модули называются сборками).

СГ> — там модуль загружается только тогда, когда вызывается какая-либо подпрограмма из этого модуля

Это всего лишь стратегия. Можно так, можно иначе.

СГ> (т.е. простая декларация IMPORT StdLog; — еще не повод загрузить в память модуль StdLog, вот когда выполнение программы дойдет до точки StdLog.String("Здравствуй Мир!"); — вот тогда модуль StdLog будет загружен в память).


Кстати, а что в Обероне нельзя раследоваться от класса размещенного в другом модуле? Или в он не компонентный?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>А что не на ассемблере?

Ну, что уж там. Тогда уж в маш. кодах.

СГ> Component Pascal для этого подходит лучше поскольку писать на нем можно гораздо быстрее и делать гораздо-перегораздо-переперегораздо меньшее количество ошибок,

Вообще-то речь шала о том, что ЖЦ не дает выигрыша в скорости. Зачем так переключать тему?

Ошибок может и меньше будет. А вот писать на нем точно будет не проще. С++ все же не из трех операторов состоит.

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

СГ> а самое главное — языку Component Pascal можно обучиться за неделю,

С нуля? Ой ли. А если не с нуля. То неделя это слишком много. Человек знающий С++ начинает писать на яве или дотнете в первый же день. А через три дня уже способен написать рабочее приложение.

СГ> а С++-су нужно обучаться несколько лет

Это преувеличение. С++ не простой язык. Но для того чтобы писать на нем приметивные программы двух лет не нужно. За 2-3 года можно гуру стать, а не то что язык выучить.

СГ> (Вы ведь не собираетесь предложить info21 — ведущему физику-теоретику, специалисту по квантовой теории поля приостановить свою науную деятельность на пару лет только для того чтобы освоить программирование на С++).

Если человеку уже умеющему программировать нужно 2 года на освоение С++, то он зря ест свой хлеб. Думаю, что и физик он будет некудышный. Так что будем реалистами. На неделю-две. Остальное по ходу пьесы.

СГ> На кой ляд использовать Си++?

А зачем ты предлогаешь? И вообще причем тут физики-теоретики я не понял. Вроде речь была об обучении детей в школах. Там С++ вообще не нужен. Там нужен какой-нить C# или VB.Net.

СГ> ПОВЫШЕНИЯ скорости исполнения на этой задаче он НЕ ДАЕТ — это специально проверялось специальными недоверчивыми программистами-студентами-аспирантами.

Язык не может давать повышения скорости вообще. Повышение дает компилятор. Ну, а тестам студентов-аспирантов доверять нельзя в принципе. Не думаю, что создатели КП были стольк же продвинуты в области оптимизации как команда Intel C++ или VC последних версий. Ну, да не о том речь.

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

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

X>Пошли в аську — 20520141. Либо по е-мейлу.

Ловлю на слове. Аськи у меня нет. А по мылу с удовольствием пообщаюсь. Вот только у тебя мыла в профайле нет. Книнь, мне его на мыло, плиз (vc as rsdn.ru).

ЗЫ

Кстати, мы оказывается одногодки. И религии сходные.

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


VD> Нда. Эдакий взгляд на жинь из дупла.

При чем тут это? Я Вам объяснил смысл Компонентно ориентированного программирования. Не хотите программировать в рамках этой парадигмы — не программируйте. Вас никто не заставляет. ООП само по себе — это тоже взгляд на жизнь из дупла: подумать только — обо всем надо думать как об объектах. Модульное программирование — это тоже взгляд на жизнь из дупла: подумать только — кроме модулей больше ничего не бывает. Структурное программирование — это тоже взгляд на жизнь из дупла: подумать только — кроме структурных конструкций нелья ничем пользоваться (запрет goto). Всякая новая более строгая дисциплина программирования — это "залезание в еще более узкое дупло" — это ограничение степеней свободы.


VD>Вообще странно слышать подобные слова от человека программирующего на Дельфи. В ней как раз есть возможность создавать наследников классов расположенных в других модулях (физических длл-ях).

Нет, не так, такой возможности нет.

VD>В Яве и дотнете все доведено до блеска и практически все классы хранятся в отдельных сборках. При этом никаких проблем с наследованием от класса находящегося в другой сборке (длл-и) нет. Кстати, а что в Обероне нельзя раследоваться от класса размещенного в другом модуле? Или в он не компонентный?

Естественно, что такая возможность есть. Я не говорю что нет возможности. В оберонах тоже можно расширять типы определенные в других модулях. Даже в Component Pascal — первом языке поддерживающем КОП это делать все равно можно. Только не надо забывать, к чему это может привести. Вам решать — как писать программу. В рамках КОП — наследоваться от не абстрактных классов определенных в других модулях нельзя, но если хотите, то наследуйтесь, но только Ваша программа, в этом случае, уже не будет удовлетворять принципам КОП.



Component Pascal отличается от Oberon-2 прежде всего тем, что в язык были добавлены ключевые слова: EXTENSIBLE, ABSTRACT, LIMITED — модификаторы типа. По умолчанию тип не расширяем (как говорится — sealed). Чтобы тип был расширяем, программист должен пометить его как EXTENSIBLE или ABSTRACT. Чтобы переменные типа можно было размещать только внутри текущего модуля программист должен пометить тип как LIMITED (это аналог приватного конструктора в С++). Если Вам не нравится парадигма КОП, то наздоровье — помечайте все типы как EXTENSIBLE и пусть их кто угодно потом расширяет...

СГ>Component Pascal отличается от Oberon-2 прежде всего тем, что в язык были добавлены ключевые слова: EXTENSIBLE, ABSTRACT, LIMITED — модификаторы типа. По умолчанию тип не расширяем (как говорится — sealed). Чтобы тип был расширяем, программист должен пометить его как EXTENSIBLE или ABSTRACT. Чтобы переменные типа можно было размещать только внутри текущего модуля программист должен пометить тип как LIMITED (это аналог приватного конструктора в С++). Если Вам не нравится парадигма КОП, то наздоровье — помечайте все типы как EXTENSIBLE и пусть их кто угодно потом расширяет...

Помоему, все это — тщетная попытка эмулировать те же sealed, public, virtual. То есть языку этого явно не хватало, и его решили "улучшить" такими вот расширениями.

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

СГ>>Component Pascal отличается от Oberon-2 прежде всего тем, что в язык были добавлены ключевые слова: EXTENSIBLE, ABSTRACT, LIMITED — модификаторы типа. По умолчанию тип не расширяем (как говорится — sealed). Чтобы тип был расширяем, программист должен пометить его как EXTENSIBLE или ABSTRACT. Чтобы переменные типа можно было размещать только внутри текущего модуля программист должен пометить тип как LIMITED (это аналог приватного конструктора в С++). Если Вам не нравится парадигма КОП, то наздоровье — помечайте все типы как EXTENSIBLE и пусть их кто угодно потом расширяет...

M>Помоему, все это — тщетная попытка эмулировать те же sealed, public, virtual. То есть языку этого явно не хватало, и его решили "улучшить" такими вот расширениями.

EXTENSIBLE - это противоположность sealed.

А public и virtual тут при чем, не объясните? Очень любопытно.

СГ>EXTENSIBLE - это противоположность sealed.

СГ>А public и virtual тут при чем, не объясните? Очень любопытно.

Сорри, хотел написать private вместо public

В тех же С# и C++ тип по умолчанию extensible, что есть правильно. C# ввел понятие sealed. Не понимаю, зачем нужен ABSTRACT. Класс с виртуальными функциями?

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

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

M> В тех же С# и C++ тип по умолчанию extensible, что есть правильно. C# ввел понятие sealed.

Могу поспорить, что наоборот лучше. Судите сами:

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

2) Расширяемых типов гораздо меньше чем не расширяемых, следовательно просто экономически выгоднее очень небольшое количество раз (каждый раз сильно обдуманно) написать слово EXTENSIBLE, чем очень много раз (у всех остальных типов) тупо писать слово sealed.

M> Не понимаю, зачем нужен ABSTRACT. Класс с виртуальными функциями?

Нет, не обязательно. В Component Pascal данный тип может не иметь ни одного абстрактного метода и даже может не иметь ни одного расширяемого метода (даже вообще может никаких методов не иметь). ABSTRACT обозначает всего лишь то, что экземпляров данного типа как таковых не бывает (они сами по себе не имеют смысла) бывают только потомки. Так, например, тип любого персистентного объекта должен быть расширением типа Stores.Store

Store = POINTER TO ABSTRACT RECORD
    (s: Store) CopyFrom- (source: Store), NEW, EMPTY;
    (s: Store) Domain (): Domain, NEW;
    (s: Store) Externalize- (VAR wr: Writer), NEW, EXTENSIBLE;
    (s: Store) Internalize- (VAR rd: Reader), NEW, EXTENSIBLE;
    (s: Store) ExternalizeAs- (VAR s: Store), NEW, EMPTY;
  END;

Его метод

PROCEDURE (s: Store) Domain (): Domain, NEW;

не расширяем (не виртуален). А все остальные методы, хоть и расширяемы (виртуальны), но ни один из них не абстрактен (не ABSTRACT). Тем не менее, тип Stores все равно объявлен абстрактным просто потому, что экземпляры этого типа самого по себе не имеют никакого смысла. Смысл имеют только переменные расширенных типов.

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

А вот этого не надо. Посмотрите сначала на даты создания оберонов (первый оберон начал разрабатываться в 1985 году) и на даты создания других языков. Тогда все разговоры "кто у кого чего перенял" поутихнут. Все у всех появлялось примерно одинаково.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>При чем тут это? Я Вам объяснил смысл Компонентно ориентированного программирования.

Изивини, то ты объясняешь свое видение. И, оно очень далего от полноценного.

VD>>Вообще странно слышать подобные слова от человека программирующего на Дельфи. В ней как раз есть возможность создавать наследников классов расположенных в других модулях (физических длл-ях).

СГ>Нет, не так, такой возможности нет.

Ага. А как же, по-твоему, работает дизайнер форм и компонетов? И как от контрола лежащего в одном пакедже можно унаследовать другой?

VD>>В Яве и дотнете все доведено до блеска и практически все классы хранятся в отдельных сборках. При этом никаких проблем с наследованием от класса находящегося в другой сборке (длл-и) нет. Кстати, а что в Обероне нельзя раследоваться от класса размещенного в другом модуле? Или в он не компонентный?

СГ>Естественно, что такая возможность есть. Я не говорю что нет возможности. В оберонах тоже можно расширять типы определенные в других модулях. Даже в Component Pascal — первом языке поддерживающем КОП

Гы. Первым. Порозительные знания.

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

Чушь. Не только можно, но нужно. Самый распространенный пример — форма в дотнете. Класс System.Windows.Forms.Form расположен в сборке System.Windows.Forms.dll. Твое приложение по определению является отедьным модулем. Оно обязано породить класс-наследник от Form. Причем Form не абстрактрый. Форму легко можно создать и отобразить с помощью следующей строчки:

new Form().Show();

при компиляции класс Form не подлинковывается к твоему проекту (это просто невозможно). Вместо этого в твоем ехе-шнике делается ссылка на System.Windows.Forms.dll и когда вызвается приведенная строчка кода эта длл загружается из из нее извлекаеся описание и код класса Form.

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

СГ>Component Pascal отличается от Oberon-2 прежде всего тем, что в язык были добавлены ключевые слова: EXTENSIBLE, ABSTRACT, LIMITED — модификаторы типа. По умолчанию тип не расширяем (как говорится — sealed). Чтобы тип был расширяем, программист должен пометить его как EXTENSIBLE или ABSTRACT. Чтобы переменные типа можно было размещать только внутри текущего модуля программист должен пометить тип как LIMITED (это аналог приватного конструктора в С++).

В С++ структура ничем кроме уровня доступа принятого по умолчанию не отличается. Так что не стоит ссылаться не этот язык. Данное утверждение справидливо тольк для С.

СГ> Если Вам не нравится парадигма КОП, то наздоровье — помечайте все типы как EXTENSIBLE и пусть их кто угодно потом расширяет...

Мне не нравится ассоциация ее с одной убогой реализацией. А сам компонентный подход мне как раз нравится. Только мне нравится когда этот подход гладко встроен в средство разработки и не трубет костылей (типа требования абстрактности для базовых типов).

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

M>В тех же С# и C++ тип по умолчанию extensible, что есть правильно. C# ввел понятие sealed. Не понимаю, зачем нужен ABSTRACT. Класс с виртуальными функциями?

К компонентности это отношения не имеет. А ABSTRACT... В Шарпе abstract означает что класс нельзя создать явно. Причем даже если в класе нет ни одного абстрактоно метода. Очень удобно для базовых классов в которых не хватает функцональности. Так же дисциплинирует так как не позволяется добавлять абстрактные методы в не абстрактный класс. На практике очень удобно.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>1) Каждый расширяемый тип представляет потенциальную угрозу расширяемости системы. Если проектировщик системы решил сделать какой-то тип расширяемым, это означает, что он очень сильно перед этим подумал. Взвесил все за и против и, наконец, решил, что сделать данный тип расширяемым все-таки нужно. Формализовал свое взвешенное волеизъявление он тем что собственноручно написал EXTENSIBLE, а у остальных типов он ничего не написал — они остались (по умолчанию) не расширяемыми.

И зачем тода в Обероне 2 по умолчанию все методы виртуальными сделаны?

СГ>2) Расширяемых типов гораздо меньше чем не расширяемых, следовательно просто экономически выгоднее очень небольшое количество раз (каждый раз сильно обдуманно) написать слово EXTENSIBLE, чем очень много раз (у всех остальных типов) тупо писать слово sealed.

Ну, как бы по факту sealed-классов почти нет. Это скорее исключение чем правило.

СГ>Нет, не обязательно. В Component Pascal данный тип может не иметь ни одного абстрактного метода и даже может не иметь ни одного расширяемого метода (даже вообще может никаких методов не иметь). ABSTRACT обозначает всего лишь то, что экземпляров данного типа как таковых не бывает (они сами по себе не имеют смысла) бывают только потомки.

Содрали с Явы и Шарпа. Вот и вопрос, им еще драть и драть пока человеческий язык получится. Не проще ли сразу использовать готовй? Если что-то не устраивает, то проще было доработать имеющийся чем полуфабрикат вроде оберона.


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

СГ>А вот этого не надо. Посмотрите сначала на даты создания оберонов (первый оберон начал разрабатываться в 1985 году) и на даты создания других языков. Тогда все разговоры "кто у кого чего перенял" поутихнут. Все у всех появлялось примерно одинаково.

Вот сморю. На дворе 2004, почти 2005. КП только сейчас получает то что Ява имела при рождении (в 96-ом). Да и не оберон это уже. А у оберона этого всего нет.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>При чем тут это? Я Вам объяснил смысл Компонентно ориентированного программирования.

...

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

Вот свеженькое определение, а не покрытое плесенью
http://en.wikipedia.org/wiki/Component-oriented_programming

Software component
A software component is a loosely defined term for a software technology for encapsulating software functionality. Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:

Multiple-use

Non-context-specific

Composable with other components

Encapsulated i.e. non-investigable through its interfaces

A unit of independent deployment and versioning

Software components often take the form of objects (from Object Oriented Programming), in some binary or textual form, adhering to some interface description language (IDL) so that the component may exist autonomously from other components in a computer.

When a component is to be accessed or shared across execution contexts or network links, some form of serialization (also known as marshalling) is employed to turn the component or one of its interfaces into a bitstream.

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

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

Чебурашка с крокодилом Геной забрались ночью в унвермаг...
— Ген! А, Ген! Тебе сапоги яловые не нужны?
— Неси их сюда.
— Немогу. В них мусор.
— Так викини его и неси их сюда.
— Немогу он меня за шкирку держит.

Вот у меня такая же ситуация.

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


VD>Изивини, то ты объясняешь свое видение. И, оно очень далего от полноценного.

Ёёёё, ЕСТЕСТВЕННО я дал свое видение — имеено так как Вы и попросили. Сначала Вы попросили дать Вам определение КОП, я его дал со ссылкой на Шиперского. Вам не понравилось — Вы попросили дать лично мое определение простыми русскими словами, я его дал — и опять Вам не понравилось. Чего же Вам надо-то было?

VD>>>Вообще странно слышать подобные слова от человека программирующего на Дельфи. В ней как раз есть возможность создавать наследников классов расположенных в других модулях (физических длл-ях).

СГ>>Нет, не так, такой возможности нет.

VD>Ага. А как же, по-твоему, работает дизайнер форм и компонетов? И как от контрола лежащего в одном пакедже можно унаследовать другой?

Секрет в том, что "пакедж" — это не DLL. Из win32 DLL Delphi не может "вынимать" классы, а может "вынимать" только переменные интерфейсных типов или типов классов все методы которых виртуальны. А дизайнер форм работает на специальной особенности дельфийского механизма RTTI — он позволяет в run-time знать не только адреса, но и имена published свойств и методов объектов. Для того чтобы натянуть VCL под C++ Builder Борланду пришлось внести в язык С++ расширение — published члены (вдобавок к существующим public, private, protected). Кстати, поскольку Delphi появилось раньше чем Java, .NET, то идею reflections они стало быть содрали у Delphi.

VD> Чушь. Не только можно, но нужно. Самый распространенный пример — форма в дотнете.

А что так сразу нужно-то? Можно не значит нужно. Вон в BlackBox форма — это не экземпляр класса потомка от класса формы, там это персистентный объект, хочется еще одну точно такую же форму — клонируй эту, а никакого класса этой формы не существует.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Кстати, поскольку Delphi появилось раньше чем Java, .NET, то идею reflections они стало быть содрали у Delphi.

June 1991
Gosling starts working on the "Oak" interpreter, which, several years later (following a trademark search), is renamed "Java."

Правда, говорится, что формально Java была объявлена в 1995:

May 23, 1995
Sun formally announces Java and HotJava at SunWorld '95.

Взято тут: http://www.ils.unc.edu/blaze/java/javahist.html

Delphi 1 (1995)
Delphi, Borland's powerful Windows programming development tool first appeared in 1995.

Взято тут: http://delphi.about.com/cs/azindex/a/dhistory_2.htm



А вообще, reflection был уже в Smalltalk (если я не ошибаюсь), а уж он то появился еще раньше.

Решил я, значит, Visual C попробовать. Установился с 5-го раза. Господи! Ну и примитив. Что за редактор у них? Да у Лексикона возможностей форматирования больше. Предварительного просмотра нет. Регулярных выражений, понятно, тоже. Попробовал картинку из фотошопа вставить — фиг. Похоже, про OLE ребята из MS не в курсе. Про гипертекст тоже. Идем дальше. Что это у нас? А, редактор диалогов. А чего это он такой убогонький? А протестировать диалог можно? Нет, только посмотреть. А чтобы протестировать, надо проект собирать. Фу! Но самое прикольное, что и функцию просто так нельзя протестировать. И кому это убожище нужно? Херим его.
Попробовать Delphi, что ли. Что за фигня вылезла? А где текст набирать? Ладно, приятель подсказал. Поместил на форму копку, щелкнул по ней, написал writeln('hello world'), запускаю, опс: "программа выполнила недопустимую операцию". И люди на этом программируют? Жалко мне их.

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

Т>Решил я, значит, Visual C попробовать. Установился с 5-го раза. Господи! Ну и примитив. Что за редактор у них? Да у Лексикона возможностей форматирования больше. Предварительного просмотра нет. Регулярных выражений, понятно, тоже. Попробовал картинку из фотошопа вставить — фиг. Похоже, про OLE ребята из MS не в курсе. Про гипертекст тоже. Идем дальше. Что это у нас? А, редактор диалогов. А чего это он такой убогонький? А протестировать диалог можно? Нет, только посмотреть. А чтобы протестировать, надо проект собирать. Фу! Но самое прикольное, что и функцию просто так нельзя протестировать. И кому это убожище нужно? Херим его.

Незнаю-незнаю, Трурль... Но половина всего что перечислено есть...Или даже больше.

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

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

Т>>Попробовал картинку из фотошопа вставить — фиг. Похоже, про OLE ребята из MS не в курсе. Про гипертекст тоже.

Зачем это? За этим

Автор: Mamut
Дата: 29.10.04

?

Здравствуйте, Сергей Губанов, Вы писали:

Могу поспорить, что не лучше. Судите сами

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

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

все что не разрешено, то запрещено

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

то, что сотворено, то сотворено для вашего блага, пропагандируйте

Что-то ты в семантике запутался, как мне кажется

СГ>Если проектировщик системы решил сделать какой-то тип расширяемым, это означает, что он очень сильно перед этим подумал. Взвесил все за и против

СГ>и, наконец, решил, что сделать данный тип расширяемым все-таки нужно. Формализовал свое взвешенное волеизъявление он тем что собственноручно написал EXTENSIBLE, а у остальных типов он ничего не написал — они остались (по умолчанию) не расширяемыми.
Закрытость для среды разработки уже вроде имеется, но на другом уровне абстракций — interface/implementation для модуля или public/private для классового типа (а в Delphi8 и для record). Эти спецификаторы накладывают ограничение на некоторую чать либо декларации класса, либо описаний методов в модуле, что собственно по моему ничем особо не отличается по семантике защиты
Для всего другого "в плане закрытости" даже в Delphi теперь есть специальные диррективы — например закрытый для дальнейшего изменения виртуальный метод или (ещё по аналогии из той же оперы) — устаревший тип.

СГ>2) Расширяемых типов гораздо меньше чем не расширяемых, следовательно просто экономически выгоднее очень небольшое количество раз (каждый раз сильно обдуманно) написать слово EXTENSIBLE, чем очень много раз (у всех остальных типов) тупо писать слово sealed.
Это совершенно не очевидное утверждение, собственно и послужившее как мне кажется неправильным посылом для предыдущего пункта.

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

WF>А вообще, reflection был уже в Smalltalk (если я не ошибаюсь), а уж он то появился еще раньше.

А если ещё точнее, то reflection восходит к старому доброму LISP, с его парадигмой "программа = данные".