Зачем два механизма ограничений?

[stanilar]

делаю через общий базвый абстрактный (или пустой) класс.

Когда зависимости удачно спроектированы - это хорошо. Но так получается не всегда. Есть определенный плюс в том, что интерфейсы позволяют сделать надстройку над уже существующими отношениями классов.

1 интерфейc обслуживает 1 класс.

Разговор изначально зашел про новую языковую возможность. У меня просто появилась мысль о том, что в языке уже все есть.

[скалогрыз]

Разговор изначально зашел про новую языковую возможность. У меня просто появилась мысль о том, что в языке уже все есть.

Интерфейсы это подобный функционал, но никак не идентичный желаемому.

[stanilar]

Интерфейсы это подобный функционал, но никак не идентичный желаемому.

Вместе с остальными языковыми возможностями, они дополняют язык до нужного соответствия.

[скалогрыз]

Вместе с остальными языковыми возможностями, они дополняют язык до нужного соответствия.

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

[stanilar]

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

[скалогрыз]

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

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

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

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

[Mikhail]

Да ладно?

Проще так, если уж на то пошло

Код: Выделить всё

PInterface = ^TInterface;
TInterface = record
obj: pointer;
Metod1: procedure (AObj: pointer; ...);
Metod2: procedure (AObj: pointer; ...);
...
end;


Ну а вообще, я о поддержке в языке говорил.

Добавлено спустя 3 минуты 5 секунд:

Второй пример, почему в С++, описание класса должно идти целиком.

По тем же причинам что и в Паскале, нет никаких проблем сделать иначе.

[скалогрыз]

По тем же причинам что и в Паскале, нет никаких проблем сделать иначе.

а вот иначе, в С++ сделать просто невозможно, из-за структуры языка. Ибо всё что использует .c/.cpp должно быть где-то описано в header-е.
В Си++ модулей нет, как и области видимости модулей.

[daesher]

а вот иначе, в С++ сделать просто невозможно, из-за структуры языка. Ибо всё что использует .c/.cpp должно быть где-то описано в header-е.
В Си++ модулей нет, как и области видимости модулей.

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