Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Ну, ФП какое-то там есть, вроде бы. Писали тут примеры. А вот с ЛП как?

Цитата Qraizer @ 21.02.11, 22:15

Ну, ФП какое-то там есть, вроде бы. Писали тут примеры. А вот с ЛП как?

наличие ссылок на функции -- еще не ФП. а с ЛП так же, как и в C++

Та ссылки-то понятно. Так же как и указатели. А вот анонимные функции, как и лямбды, уже ближе.

Цитата korvin @ 21.02.11, 21:41

Цитата D_KEY @ 21.02.11, 21:25

Они являются логическими единицами программы? А как же классы и ОО-декомпозиция?

модули ортогональны каким-бы то ни было парадигмам. хочешь, юзай ООП, хочешь -- процедурное [, хочешь (если бы делфи позволяло) -- ФП. или там ЛП.]

Если модуль - это просто контейнер, то соглашусь. Но ведь модуль - это логическая единица декомпозиции программы. С этой точки зрения, парадигма играет достаточно большую роль.

Добавлено 22.02.11, 06:57

Цитата Qraizer @ 22.02.11, 04:41

Та ссылки-то понятно. Так же как и указатели. А вот анонимные функции, как и лямбды, уже ближе.

В отсутствии gc лямбдами ты не всегда сможешь воспользоваться в полную силу(если только не станешь все копировать), сможешь легко получить обращение по ссылке к уже уничтоженному объекту, да и с shared_ptr можно проблем обрести и отлавливать потом утечки памяти... Это конечно решаемо с помощью weak_ptr'ов, но ведь все опять же руками...

Цитата D_KEY @ 21.02.11, 21:25

Можешь обосновать роль модулей в Delphi?

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

Сообщение отредактировано: --Ins-- - 22.02.11, 10:24

Цитата --Ins-- @ 22.02.11, 10:22

Цитата D_KEY @ 21.02.11, 21:25

Можешь обосновать роль модулей в Delphi?

Модули - это средства декомпозиции программного кода, в отличие от классов, которые являются средством декомпозиции программной модели

Так зачем нужна декомпозиция модулей, если есть декомпозиция классов?

Цитата D_KEY @ 22.02.11, 10:23

Так зачем нужна декомпозиция модулей, если есть декомпозиция классов?

Читай выше, я добавил

Цитата --Ins-- @ 22.02.11, 10:22

Модули обеспечивают инкапсуляцию, подобно классам, но это совсем другая инкапсуляция: классы посредством инкапсуляции регулируют доступ к данным объекта, модули - к коду

В чем отличие "данных" и методов объекта/класса от кода с точки зрения ООП?

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

Цитата --Ins-- @ 22.02.11, 11:02

D_KEY, код - это не только методы, это еще и типы, плюс методы, которые к обработке данных класса отношения не имеют (статик-методы).

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

Цитата D_KEY @ 22.02.11, 11:28

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

Угу. Ну и как тут классы заменяют модули в этом случае?

Цитата --Ins-- @ 22.02.11, 11:30

Угу. Ну и как тут классы заменяют модули в этом случае?

Вопрос лишен смысла, ты ведь сам сделал упор на статические методы

Цитата --Ins-- @ 22.02.11, 11:30

Цитата D_KEY @ 22.02.11, 11:28

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

Угу. Ну и как тут классы заменяют модули в этом случае?

В каком в этом? Про гибридные языки я уже написал.
Да и в ООП языке статические методы можно рассматривать как статический интерфейс класса.

Что тебе еще нужно от модулей?
Со всем справляются или правило каждый класс в отдельном файле, или более универсальные единицы трансляции, как в С++(с отделением интерфейса от реализации). Модули же на уровне логики оказываются невостребованными.

D_KEY, ОК, давай на примере, который уже был...

unit GDIPOBJ;
 
// Опущено
 
initialization
begin
  // Initialize StartupInput structure
  StartupInput.DebugEventCallback := nil;
  StartupInput.SuppressBackgroundThread := False;
  StartupInput.SuppressExternalCodecs   := False;
  StartupInput.GdiplusVersion := 1;
  // Initialize GDI+
  GdiplusStartup(gdiplusToken, @StartupInput, nil);
 
end;
 
finalization
begin
 
  if assigned(GenericSansSerifFontFamily) then GenericSansSerifFontFamily.Free;
  if assigned(GenericSerifFontFamily) then GenericSerifFontFamily.Free;
  if assigned(GenericMonospaceFontFamily) then GenericMonospaceFontFamily.Free;
 
  if assigned(GenericTypographicStringFormatBuffer) then GenericTypographicStringFormatBuffer.free;
  if assigned(GenericDefaultStringFormatBuffer) then GenericDefaultStringFormatBuffer.Free;
 
  // Close GDI +
  GdiplusShutdown(gdiplusToken);
end;

Как с этим справляются классы? Ну-ка, покажи-ка мне костылек?

Сообщение отредактировано: --Ins-- - 22.02.11, 11:46

Цитата --Ins-- @ 22.02.11, 11:45

D_KEY, ОК, давай на примере, который уже был...

Я же отвечал. Создаем класс для работы с GDI+, работаем с объектом этого класса. Более того, может существовать абстрактный класс(интерфейс), наследником которого является данный, наравне с другими классами, реализующими тот же функционал, но другими средствами.
Можешь сделать синглтон, если угодно, можешь сделать один статический объект внутри класса, отвечающий за инициализацию/очистку. В чем проблема?
Смешивать низкоуровневую логику(кроме того, выполненную в структурном стиле) с высокоуровневой не стоит.