При пчтении треда обратил внимание по-моему на очень интересный аспект:
Edd.DragonМне надо реализовать БД и оконный клиентский интерфейс к ней, при этом нужно реализовать более-менее адекватную архитектуру приложения, которую можно развивать в дальнейшем. Для этого не подойдут, ни Паскаль, ни С. Но подойдет уйма языков, включая, С++, Дельфи, C#, Java и даже PHP c HTML.

Вот и вопрос родился сам собой.
Положим, в большом проекте ( многопоточное приложение) есть некий бизнес-объект ( сотни разных их в большом проекте!)
Задача-требование №1 - проверить права пользователя при обращении к экземпляру объекта, и в случае недостатка прав вывести соответствующее сообщение.
Давайте угадаю, как поступит настоящий дельфи-разработчик:
Вариант 1: Допишет в реализацию методов-свойств класса что-то вроде
IF CheckPermissions(context) THEN.... ELSE ...
Вариант 2: Отрефакторит код так, что все обращения к объекту будут проводиться через функцию вида
PermitAccess(obj: BLL; context: ...): BLL;
Вариант 3: Продвинутый математически разраб вспомнит, что можно использовать композиции функций - тоже рефакторит код, выставляя наружу делегаты с конечным набором сигнатур
Вариант 4: Продвинутый технически разработчик начнет ковырять стек...

И какой вариант вам ближе идеологически? :-)

А теперь еще предположим, что приложение у нас , и нам последовательно, постепенно, через определенные промежутки времени, выставляются следующие требования:
2. Оказывается, объект BLL "тяжелый" (например, куб пересчитывает). и тормозит. Надо бы в GUI добавить возможность, чтобы при работе с этим объектом менялся вид курсора мыши.
3. Выяснилось что, если к-л поток обращается к объекту BLL занятому своей работой, то может произойти нечто страшное. Посему надо так "заморозить" объект, чтобы другие потоки получали отказ в виде исключения, если объект занят работой.

Но. все эти три требования элегантно(!) и эффективно(!!) разруливаются в ЯП имеющих поддержку АОП. Например, в паскале, который Оберон :) А вот "уйма языков, включая, С++, Дельфи, C#, Java и даже PHP c HTML" - она в пролете:
общий недостаток для всех вариантов - надо писать гораздо больше кода, чем это требуется (а требуется написать три метода. Три небольших требования = три небольших метода)
Плюс:
В1 - Уже при реализации второго требования поверх первого в коде наступит КАША
В2...В3 - Необходим ой-ой-ой какой масштабный рефакторинг. (сотни объектов - тысячи обращений)

eBlondink0В2...В3 - Необходим ой-ой-ой какой масштабный рефакторинг. (сотни объектов - тысячи обращений)
В2...В4 - Необходим ой-ой-ой какой масштабный рефакторинг. (сотни объектов - тысячи обращений - тысячи изменений)

Про паскальУ детей отказ мозга? Эти штуки испокон веков разруливались такими вещами, как семафоры, мутексы, критические секции.


Может, покажете зелени, как добавив новый код, с "семафоры, мутексы, критические секции", можно добиться реализации хотя бы первого требования - не меняя ни строки существующего кода доступа к объекту, лишь за счет минимального расширения декларации самого типа? Просто мне кажется, Ваше "испокон веков" сильно попахивает Вариантом №1

Про паскальВо-первых, на Delphi редко пишут бизнес-логику (в основном интерфейсы). Всякие штуки вроде проверок доступа - пишутся на серверах (т.е. на PL/SQL, Java, даже C#).
Слово "Delphi" в контексте поставленной задачи некритично. C# Java etc они в этом плане находятся на уровне Delphi. Ах и увы.

Про паскальа прав доступа к классу разгуливаются на уровне свойств

См. "варианты №1... №3" и особенно, их недостатки.

Про паскаль(выставлять поле в public доступ, не через свойства - до такого только детсадовец мог додуматься).

Т.е. обернуть поле в public-доступе соотв. функционалом Вы не можете? Так сразу бы и говорили - мол, не осилили.

ZyK_BotaNкак человек не знающий оберон спрашиваю:
в неме есть хоть 10я доля делфовских библиотек?
Если Вы в коде мешаете JVCL c VCL, ZeosLib с MyDAC и Indy с сокетами то, скорее всего, десятой доли библиотек для Вас там не наберется.